[Scons-dev] Branching/cloning policy

[Chris BeHanna]

On Aug 9, 2012, at 12:58 , Dirk Bächle <tshortik at gmx.de> wrote:


> On 09.08.2012 19:39, Gary Oberbrunner wrote:

>> On Thu, Aug 9, 2012 at 1:28 PM, Russel Winder<russel at winder.org.uk>  wrote:

>>> My worry with the single repository with default a mirror and a named

>>> branch is that in order to process any pull requests you have to accept

>>> the presence of the named branch in the mainline repository?

>> That is true.  Mercurial branches are permanent and contagious.  The

>> branch a commit was created on is recorded as part of that commit, so

>> anywhere that commit is merged to must contain that branch.  For

>> feature branches, that could be seen as a good thing (an extra bit of

>> useful metadata).  But it is worth remembering.

>> 

> I'd say that in this case it is perfectly reasonable to use a named branch for all the "D" development work. Just like the signature refactoring, or a release branch, it should stand on its own since you're probably touching a lot of SCons' guts.

> The "Java improvements" (if they should ever happen) would be a fine candidate too.


	The trouble is that this branch then lives in all clones for all time.  If it is merely the default branch of its own clone, then it can still stand on its own, as you say.  I get the feeling that hg branches are really only intended for release-oriented work (e.g., forking off a stabilization/bugfix branch from the trunk prior to cutting a release), or for otherwise-agreed-should-live-forever purposes.

	That said, now that hg can close branches, at least the "hg branches" and "hg log" views don't have to be cluttered, but those branches are still there, nonetheless.

	If one does feel the need to separate the development in the same repository, anonymous branches and bookmarks can also be a decent way to go.  Merge in at the end, and the number of heads upstream doesn't change.

-- 
Chris BeHanna
chris at behanna.org