On Aug 9, 2012, at 12:58 , Dirk Bächle <[email protected]> wrote:
> On 09.08.2012 19:39, Gary Oberbrunner wrote:
>> On Thu, Aug 9, 2012 at 1:28 PM, Russel Winder<[email protected]> 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
[email protected]
_______________________________________________
Scons-dev mailing list
[email protected]
http://two.pairlist.net/mailman/listinfo/scons-dev
