[Numpy-discussion] DVCS at PyCon

[Martin Geisler]

Stéfan van der Walt <stefan at sun.ac.za> writes:

> Hi Martin
>
> 2009/4/13 Martin Geisler <mg at lazybytes.net>:
>> In Mercurial it creates a *named
>> branch*, which are imbedded in the history and are used for long-term
>> development branches. Names of Git branches are not recorded in the
>> history and are thus well-suited for local experiments.
>
> [...]
>
>> The bookmarks extension let you assign names to the heads, it is
>> inspired by the way Git branches work. Unfortunately the bookmarks are
>> not yet transferred over the network when you do push/pull, but this is
>> of course a planned feature.
>
> Thanks for the info. Maybe you can also help me out with the following
> questions: I'd like to know how to duplicate git's branch workflow in
> Mercurial.
>
> - How do you create a new head when you are working on top of the
> current head? Do you have to make a dummy commit and then commit on
> top of (TIP - 1) whenever you need a new "branch"?

Yeah, you can create multiple heads like that. In general, let's say the
current tip of the tree is T:

  ... --- T

You've just cloned this tree from the Numpy server. To make your head
you will just do a commit:

  ... --- T --- S

In Mercurial there is no notion of "my head" and "your head" and
(Git-style) branches are just implicitly made from how the changeset
graph develops. So if I have also started from T and made a commit my
tree will look like this:

  ... --- T --- M

and so far neither of us knows about the other guys branch. We can both
tell that we've done something by using 'hg outgoing', which will tell
you that the S changeset is missing at Numpy, and tell me that the M
changeset is missing.

Now imagine I push my change to Numpy -- if you do 'hg incoming' you'll
see that there is a missing changeset, and if you do 'hg pull' your tree
will end up like this:

            S
           /
  ... --- T
           \
            M

The files in your working copy will still be at the S changeset ('hg
parents' will say S), but you can now see that your changeset has
created a branch with regard to the Numpy repository.

But you can continue working and make U, V, etc:

            S --- U --- V
           /
  ... --- T
           \
            M

In the mean time I might commit N and O to my tree:

  ... --- T --- M --- N --- O

and push this to Numpy. If you pull from Numpy you'll now see

            S --- U --- V
           /
  ... --- T
           \
            M --- N --- O

At some point you can decide to merge your branch into the main branch
and get a merge changeset X:

            S --- U --- V
           /             \
  ... --- T               X
           \             /
            M --- N---- O

> - Is it possible to remove a head without merging it, discarding the
> children?

Or your can decide to forget about your branch by making a local clone
where you only ask for the O head:

  hg clone -r O repo repo-with-O

The new repo-with-O clone will look like this:

  ... --- T --- M --- N --- O

i.e., it will be exactly like what's on Numpy at this point in time.

The strip command from the mq extension gives an alternative way to do
this from within a single clone:

  hg strip -r S

will remove S and all child changesets, i.e., S, U, V and the result
will again be exactly what is on Numpy.

-- 
Martin Geisler

VIFF (Virtual Ideal Functionality Framework) brings easy and efficient
SMPC (Secure Multiparty Computation) to Python. See: http://viff.dk/.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20090413/70b2fdb0/attachment.sig>