[Numpy-discussion] DVCS at PyCon

[Martin Geisler]

David Cournapeau <david at 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:

  http://thread.gmane.org/gmane.comp.python.numeric.general/29117

> 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
history.

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