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