[Numpy-discussion] DVCS at PyCon

David Cournapeau cournape at gmail.com
Fri Apr 10 22:56:40 EDT 2009


On Sat, Apr 11, 2009 at 6:16 AM, Eric Firing <efiring at hawaii.edu> wrote:

>
> On my laptop, switching back and forth between the two active branches
> of mpl takes about 3 s for the first and 2 s for the second, timed by
> counting in my head.

I think Ondrej cares more about being faster than most of us - he is
just too fast for most of us :) I don't think speed should be an
argument, because both are fast enough.

>
> I'm on thin ice here, because for my own work I have not been using
> named branches.
>
>>     - you can't remove them later, it is in the repository 'forever'
>
> They can be removed with the strip command which is in the mq extension,
> but one must identify the root of the branch and supply that to strip.
> There may be some limits and gotchas.

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 ? 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 ?

> For very lightweight local branching there are bookmarks, which allow
> one to make a local, changeable label for a given head within a repo.
> Again, such a local branch can be eliminated via strip--although I am
> not sure there is much point in doing so.  To go this route, I suspect
> one would first commit a tag, set the bookmark, make whatever changes
> and commits are desired, etc.  The point of the tag would be to make it
> easy to tell strip where to start stripping.

Ah, I think I was confused between named branches and bookmarks. From
the description of bookmarks, this actually looks nearer to the git
cheap branch concept. I should really try it to get a good
understanding, though.

> Overall, it appears to me that for someone who has never
> used a VCS, or for someone used to svn, hg has a lower barrier to entry
> than git.

It may be true for branches - but the basic
(commit/log/pull/push/clone) is almost exactly the same between the
two of them (and for bzr as well). So for someone who keeps a svn-like
workflow, I don't see big differences between the tools.

>>
>> One big potential with the way git does branching is review - gerrit
>> (the code review tool used by Google for android) looks really nice.
>
> How is the code review related to the branching options in git?

A good explanation is there:

http://groups.google.com/group/repo-discuss/browse_thread/thread/f8365b4217157cd4/2c3c729082bdd1b7?#2c3c729082bdd1b7

If you have used rietveld (from which gerrit was forked), it is a bit
similar UI-wise, but git makes some things more automatic (if the
review is good, the changes are automatically merged, for example).
But again, I said potentially because we would need to really try it
with other people for review to get a real idea. If there is one thing
that I learned why using different tools, it is that the only way to
know about them is to stop reading about them, and actually use them
:)

> You can easily do diffs between changesets within a repo, regardless of
> whether they are on different named branches, and the diffs can be
> specific to a file or subdirectory.  Changesets can be identified by
> branchnames, tags, bookmarks, sequential numbers, or hash ID. For diffs
> between directories, there is an rdiff extension that is not distributed
> with hg.  I haven't tried it.

Yes, I have just tried this as well, and it works as I expected - once
I understand that what mercurial calls a revision includes branch name
as well. It is a bit slower than git, but really nothing prohibitive.

David



More information about the NumPy-Discussion mailing list