[Numpy-discussion] DVCS at PyCon
Fri Apr 10 21:56:40 CDT 2009
On Sat, Apr 11, 2009 at 6:16 AM, Eric Firing <firstname.lastname@example.org> 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
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
> 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:
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.
More information about the Numpy-discussion