David Cournapeau <da...@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/.
pgpzlMRQz5I8V.pgp
Description: PGP signature
_______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
