[Scons-dev] Version control (was Re: Scons 2.3.2 regression, D tool...)

[Mark A. Flacy]

On Saturday, August 09, 2014 02:18:49 PM William Blevins wrote:
> > 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.


I've been using DVCs since 2003 (Tom Lord's larch, followed by tla, hg, bzr, 
and recently git).  I've even looked at fossil and darcs.

Git is the strange one of the bunch. There are things in git that go by the 
name of "X" that have things in the other DVCSs that are also named "X" that 
are almost naming the same concept.  It's the details that throw you.

Such as git thinks that history is malleable by default while none of the 
other DVCSs do.  (That's why you have to turn on the rebase extension to hg; 
it's part of the base code, but using it changes the basic model.)

My colleagues at work are moving from ClearCase UCM to git and they eff things 
up every day.  (So do I.  The git user interface is absolutely horrible.) A 
different colleague of mine moved from ClearCase UCM to Mercurial and hasn't 
had a problem.  (In fairness, he's working pretty much by himself so I don't 
expect that his merge problems are that complicated.)

http://mercurial.selenic.com/wiki/BranchingExplained describes the differences 
rather well, I think, on the branching strategies of the two DVCSs.  A 
changeset (aka commit object) in hg does not have to have a named reference to 
survive.

http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/ also has 
good information.

>From what I've read on hg's bookmark implementation and what I've seen 
recently on git's branching, I think that 
http://mercurial.selenic.com/wiki/Bookmarks is a very close analog.  Note that 
the bookmark namespace is global, not local like the git branch namespace.

-- 
Mark A. Flacy