[Numpy-discussion] DVCS at PyCon
Martin Geisler
mg at lazybytes.net
Mon Apr 13 05:22:21 EDT 2009
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>
More information about the NumPy-Discussion
mailing list