What is a branch?

Martin Geisler mg at daimi.au.dk
Fri Feb 15 16:42:29 CST 2008


"John D. Mitchell" <jdmitchell at gmail.com> writes:

> On Thu, Feb 14, 2008 at 11:28 PM, Martin Geisler <mg at daimi.au.dk> wrote:
> [...]
>>  Right, but would it not be just as easy to use seperate clones to
>>  identify the branches?
>
> Yes.

Good, thanks for the confirmation. That was always my problem when I
read the description of named branches in the hg book and on the wiki:
At first glance, it seems like a solution to something which already has
a simple solution (several clones).

On a conceptual level having multiple clones is easier to understand,
since that is the basic model used by Mercurial anyway when you pull
From some other developer's repository.

Now I see that named branches are a way to "merge" several clones into
just one repository (except that the name is sticky). Maybe there should
be commands that make this explicit? I imagine two commands:

* merge: give it several repositories and it will combine them into one
  repository with a (local) named branch for each repository.

* split: do the opposite, split a repository with several named branches
  out into several clones.

Well, maybe there wouldn't actually be a need for such commands, but at
least it would be nice to think of the connection between (local) named
branches and clones in that way.

>>  [...] how to easily switch from one clone to another and still have
>>  the correct clone in my PYTHONPATH. Perhaps one could use a little
>>  extension that updates a symlink to point to the correct clone...).
>
> Symlinks are one way.
>
> They way I use to deal with things like this that need to change based
> on e.g., location is to create simple shell script to set/modify them
> and invoke the underlying tools. [...]
>
> For my upcoming talk at SD West (Give IT a REST), all of this is part
> of the sample code that I'm distributing in a tarball that contains
> the complete hg repository so people can follow all of the (big) steps
> by checking out the various revisions of the software.

That will be interesting to see this approach in action, for my initial
thought was that it would be a bit tedious to write such a wrapper for
all operations.

>>  The advantage of seperate clones would be that I can easily delete a
>>  clone that is no longer needed, whereas branches are sticky and will
>>  leave a trace in the repository when merged. For a branch like "v2"
>>  it would probably be good with such a trace, but with a branch like
>>  "my-test-feature" it would be somewhat ugly.
>
> Indeed.
>
> This is exactly the same argument as for using a DSCM like hg instead
> of a CSCM like perforce.

So I guess that means that the local named branches extension ought to
be more prominently used, for as it is now, I wouldn't want to create a
named branch for a silly feature when I know that it leaves a trace in
the repository.


Thanks for the input!

-- 
Martin Geisler

VIFF (Virtual Ideal Functionality Framework) brings easy and efficient
SMPC (Secure Multi-Party Computation) to Python. See: http://viff.dk/.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 188 bytes
Desc: not available
Url : http://selenic.com/pipermail/mercurial/attachments/20080215/62d5c6b3/attachment.pgp 


More information about the Mercurial mailing list