effective use of in-repository branching

[Georg-W. Koltermann]

Am Mittwoch, den 07.02.2007, 15:06 -0600 schrieb Matt Mackall:
> On Wed, Feb 07, 2007 at 12:39:19PM -0800, Stuart Marks wrote:
> > Some colleagues and I have been discussing the use of Mercurial's 
> > named-branch feature to keep patches and mainline development in the same 
> > repository. Named branches seem almost ideal for doing this, but there are 
> > a couple stumbling blocks.
> > 
> > For example, suppose we have the following sequence of revisions:
> > 
> > 81----82(1.0)----83----84(tip)
> > 
> > Let's say that rev 82 corresponds to a 1.0 release of the project, so it 
> > was tagged as such. Post-1.0 development continues with revs 83, 84, and so 
> > on.
> > 
> > Now let's say that we need to issue a patch for 1.0 but we don't want to 
> > mix in the work-in-progress from revs 83 and 84. We'd update a working copy 
> > to rev 82, implement the patch, and commit it with a new branch name. This 
> > would result in:
> > 
> > 81----82(1.0)----83----84
> >         |
> >         |
> >         +----85[1.0patch](tip)
> > 
> > Structurally, this is perfectly correct. However, there are some things 
> > about the situation now that seem quite inconvenient.
> > 
> > (1) Common usage is for developers to do "pull -u" to keep up to date with 
> > a shared repository. Unfortunately, this updates to the tip, which is now 
> > on a branch. 

...
some
> > It seems to me that a very lightweight notion of "default branch" would be 
> > useful. I guess this would be stored in .hg/hgrc. It would have the 
> > following semantics:
> > 
> > a) Cloning a repo would propagate the default branch (if any) into the new 
> > repo, and then update to the default branch (if any), otherwise to the tip.
> 
> We currently don't have any mechanism for transmitting info that's not
> "checked in". And I'd like to avoid adding one, as it would mean
> having to re-solve a large set of problems. So the .hg/hgrc thing
> doesn't really work.
> 
> I also don't really like the idea of having a hard-coded name like "HEAD"
> or "default" that's the default for clone operations.

Note that the default branch may need to be different for different
people.  After all, branches are about separating development streams,
so one group may work on branch A, another one on branch B.

In light of this I think having the default branch specified in .hg/hgrc
is still a good idea.  The default branch should not be transmitted
anyways, everyone will need to pick her or his own, just like the
default push and default pull and stuff.

I am currently working in a very similar situation with different
development streams sharing a repo.  I'm not using branches, because I
can't see them easily, e.g. in hgk or in the web browser.  Instead I do
eyeballing, looking at hgk and knowing which developer is supposed to
work on which stream.  This kind of sucks.  What I would love to have is
a kind of "branch mask" that makes hgk show just a selected set of
branches (namely the particular branch I'm working on, and in addition
the integration branch where all work is collected when ready).  And it
should color-code by branch name :)

--
Regards,
Georg.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3441 bytes
Desc: not available
URL: <http://lists.mercurial-scm.org/pipermail/mercurial/attachments/20070208/2fa15c9e/attachment-0001.bin>