[Numpy-discussion] DVCS at PyCon

[Martin Geisler]

David Cournapeau <cournape at gmail.com> writes:

> Ok, will look at it more closely (I have just made a hg repo from the
> numpy git one on my machine). I am still confused about how named
> branches are supposed to work (the hg book is a a bit light on this).
> For example, let's say I want to create a branch from a given
> revision/tag, how should I do it ?

You update to the revision, edit and make a commit. Please see below.

> Since hg branch does not take an -r revision, I tried to create the
> branch first, and then use hg up -r N, but it did not commit as I
> expected from a git perspective:
>
> hg branch foo
> hg up -r 500
> hg log # show me last revision independently from the branch changes.
> Not so surprising given that the branch was created from the tip of
> default.
> hg ci -m "bla"
> hg branches # no branch foo ?
>
> What am I doing wrong ?

As we pointed out to Ondrej Certik on the Mercurial list, 'hg branch' is
very different from 'git branch'. 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.

In Mercurial you can create an unnamed branch from any point in the
changeset graph by updating to that point and making a commit:

  hg update 123
  # edit files
  hg commit -m 'My change.'

If you make a commit from a changeset which already has other child
changesets, then you've created an unnamed (anonymous) branch. You can
see this with 'hg heads' -- it shows you the changesets without
children, and having more than one of these means that there are some
unmerged branches.

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.

If you want to let others know about a branch you're working on, you can
always put up a separate clone with that branch -- then just delete the
clone if you want to throw away the branch.

If you have multiple heads in a repository, it is easy to separate them
into separate clones:

  hg clone -r some-rev repo repo-with-some-rev

This makes repo-with-some-rev contain some-rev and all ancestor
revisions -- but no other heads. You can merge such splitted clones
again by pulling in changesets from another 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/9787b5a9/attachment.sig>