[Numpy-discussion] DVCS at PyCon

Martin Geisler mg@lazybytes....
Mon Apr 13 04:22:21 CDT 2009

David Cournapeau <david@ar.media.kyoto-u.ac.jp> writes:

Hi David x 2 :-)

I've put the David Soria on Cc since he wrote the bookmarks extension,
maybe he can give additional information. The thread can be found here:


> Martin Geisler wrote:
>> [...] changesets are in a parent-child relationship. So if I cloned a
>> repository at changeset T:
>>   ... --- T
>> I'm free to make new commits:
>>   ... --- T --- A --- B
>> And you can do the same:
>>   ... --- T --- X --- Y --- Z
>> I can pull in your changesets without disrupting my own work:
>>             X --- Y --- Z
>>            /
>>   ... --- T --- A --- B
>> Your changesets will be attached to the graph at the point where you
>> made them, the same for my changesets. I don't have to merge at this
>> point, instead I can continue with my work even though the repository
>> has multiple heads (changesets with no childre). So I make C:
>>             X
>>            /
>>   ... --- T --- A --- B --- C
>> I might now decide that I like your X, Y changesets but not Z, so I
>> merge them Y into my line of work to create D:
>>             X --- Y --- Z
>>            /       \
>>   ... --- T         `---- D
>>            \             /
>>             A --- B --- C
>> or I might decide that I don't need your changesets and discard them by
>> cloning or by the strip command from mq (one or the other):
>>   hg clone -r C repo repo-with-C
>>   hg strip X
>> The result is a repository that has only the history up to C:
>>   ... --- T --- A --- B --- C
>> So I think it's nonsense to say that Mercurial is like Subversion here:
>> you pull in changesets when online and you can make new commits, merge
>> commits, delete commits while offline.
>> Git has the advantage that it names these branches in a nice way, and
>> you can work with these names across the network. The bookmarks
>> extension for Mercurial is inspired by this and lets you attach local
>> names to heads in the graph.
> Thanks a lot for this information, that's really useful.

Great! I trust that you guys will let me know when/if you get tired of
this discussion :-)

> I am still a bit confused about how this works at the UI level,
> though, w.r.t one clone/branch. In bzr, there is one branch and at
> most one working tree / repository (at least that's how it is used
> generally). It looks like hg, while being based on one branch /
> repository, is a more flexible. One thing which converted me to git
> from bzr was the UI for branch comparison. My basic reference is for
> release process. Currently, in numpy, we have the trunk, and
> potentially several release branches, which would be one head each if
> I get the vocabulary right:
>                 --- A --- B --- C (1.2.x head)
>               /
> trunk --- Release 1.2.0 --- Release 1.3.0 --- (mainline head)
>                                  \
>                                    D --- E --- F --- (1.3.x head)

> How do you refer to different branches from one clone ? For example,
> if I want to see the differences between mainline and 1.3.x branch,
> cherry-pick things from mainline into both 1.3.x and 1.2.x, etc... How
> does it work with bookmarks ?

You write things like

  hg diff -r F -r tip

where 'tip' is a built-in name that always point to the newest revision
in a repository. If you have a bookmark named 'numpy-1.2.x' on F you
could write:

  hg diff -r numpy-1.2.x -r tip

As for cherry-picking the recommended way (in both Git and Mercurial, as
far as I know) is to do the commit on the oldest relevant branch and
then merge this branch into younger branches and finally into the
mainline. This way each branch is a strict subset of the next branch,
and mainline contains all commits on all branches.

But of course one might realise too late that a changeset on mainline
should have been made on, say, the 1.3.x branch. In case one can apply
the change as a new changeset by exporting it from mainline and
importing it on 1.3.x:

  hg export tip > tip.patch
  hg update -C 1.3.x
  hg import tip.patch

The transplant extension for Mercurial can help with this, probably with
better handling of merges, but I don't have any real experience with it.

> Also, do we have to agree on everyone using bookmark to communicate
> each other (one repository for everything on main numpy web
> repository), or can people still use clones for every branch, and
> "putting things back into bookmarks" when they push things in the
> official repo ?

The bookmarks is a convenience layer on top of the basic functionality
in Mercurial. They let you attach a name to a changeset just like a tag,
but unlike tags the names move around: if you make a commit based on a
changeset F with 'numpy-1.3.x', the child changeset will now have the
bookmark 'numpy-1.3.x'. This way bookmarks become moveable pointers into
the history, similarly to how Git heads point to changesets in the

At the moment, bookmarks are even local to a repository, but it is
planned to add support for looking them up remotely and for transferring
them on push/pull. But right now you cannot tell if I'm using bookmarks
to keep track of the heads in my clone.

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.scipy.org/pipermail/numpy-discussion/attachments/20090413/3919875d/attachment.bin 

More information about the Numpy-discussion mailing list