[Scons-dev] Scons 2.3.2 regression, D tool...

[William Blevins]

>
> The core issue here is that Mercurial enforces maintaining the names of
> branches in all repositories. Thus the technique of internal feature
> branches fails with Mercurial. This leads to having branches only for
> long lived things such as maintenance branches. Everything else needs to
> be on default. This means clones for feature branches or use of
> bookmarks (MQ seems to be deprecated in favour of rebase and graft and
> things I don't understand about Mercurial – which includes bookmarks).
> Our problem is that it seems that maintaining a long running
> synchronized clone of a default branch leads Mercurial to having
> problems on a final merge. Advice from a Mercurial expert was that
> actually the result was fine, just ugly. Gary felt it was an ugly too
> far and that we should not use that way of merging. Nothing wrong there
> per se. It just brings into stark relief that we do not have a
> reasonable workflow just now.


Bookmarks have been alright, but only for like 1 or 2 small commits and
trying to work on several small independent articles is frustrating.  To
get around this I either clone a new repo for that item or I bootstrap a
GIT repo and manage everything that way until I'm done.  It may be my
misunderstanding of the way Mercurial was meant to be used.  Too many
important features come as plug-ins rather than base-line features. I have
co-workers who use HG for their projects and I was trying to see I was just
being silly, but there response lead me to believe that they cloned a new
repo per work item.

-William


On Sat, Aug 9, 2014 at 2:05 PM, Russel Winder <russel at winder.org.uk> wrote:

> On Sat, 2014-08-09 at 13:33 -0400, William Blevins wrote:
> > Fair; I realize its non-trivial.  My complaints with Mercurial aren't
> > related to one particular event.  It's more a personal preference in tool
> > usability.
> >
> > If HG suites the needs of the team, I'll just have to muddle through it.
> >
> > Again, you are right.  This issue has nothing to do with Mercurial.
> >
> > Sorry,
>
> Please don't apologise for raising a perfectly reasonable point, there
> is nothing wrong with that.
>
> The history of this is that Python went with Mercurial and Steven wanted
> to go with Mercurial, so we went with Mercurial. At the time it seemed
> fine and reasonable and I had no problem with it. And in many ways still
> don't even though I prefer Git for the remote tracking branches and
> transient internal feature branches. (Well actually I still prefer
> Bazaar, but that is now an ex-DVCS, given it's level of support since
> Canonical have dropped funded support.)
>
> The core issue here is that Mercurial enforces maintaining the names of
> branches in all repositories. Thus the technique of internal feature
> branches fails with Mercurial. This leads to having branches only for
> long lived things such as maintenance branches. Everything else needs to
> be on default. This means clones for feature branches or use of
> bookmarks (MQ seems to be deprecated in favour of rebase and graft and
> things I don't understand about Mercurial – which includes bookmarks).
>
> Our problem is that it seems that maintaining a long running
> synchronized clone of a default branch leads Mercurial to having
> problems on a final merge. Advice from a Mercurial expert was that
> actually the result was fine, just ugly. Gary felt it was an ugly too
> far and that we should not use that way of merging. Nothing wrong there
> per se. It just brings into stark relief that we do not have a
> reasonable workflow just now.
>
> I am getting to the stage of not doing anything because any process I
> use leads to problems.
>
> I am thinking that we should use clones for feature branches
> synchronizing with the mainline and even publish them but before making
> the final pull request perform a full rebase so as to create a pull
> request sitting on the current mainline default/tip.
>
> Anatoly had, I believe, an alternative suggestion, but I have forgotten
> what it was. As he is more of a Mercurial expert, his suggestion may
> well be far more sensible.
>
>
> --
> Russel.
>
> =============================================================================
> Dr Russel Winder      t: +44 20 7585 2200   voip:
> sip:russel.winder at ekiga.net
> 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel at winder.org.uk
> London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
>
> _______________________________________________
> Scons-dev mailing list
> Scons-dev at scons.org
> http://two.pairlist.net/mailman/listinfo/scons-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://two.pairlist.net/pipermail/scons-dev/attachments/20140809/79218bf7/attachment-0001.html>