[Numpy-discussion] DVCS at PyCon

[Eric Firing]

David Cournapeau wrote:
> 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.

Also, if you just want to remove the branch from the list of branches, 
as opposed to expunging the changesets it contains, then you can use
hg commit --close_branch.  Strangely, though, you then have to use the 
-a option of branches to exclude it from the list; and you can still go 
back to it and resume work on it.

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

Try something like this sequence (substituting your editor for "z" and 
adding random junk each time):

  504  mkdir hgtest
   505  cd hgtest
   506  hg init
   507  z test.txt
   509  hg add
   510  hg commit -m first
   511  z test.txt
   512  hg commit -m second
   513  z test.txt
   514  hg commit -m third
   515  hg log
   516  hg up -r 1
   517  hg branch from1
   518  hg tag from1tag
   519  hg status
   520  hg log
   521  z test.txt
   522  hg commit -m "first change after tag on from1"
   523  hg up -r default
   524  cat test.txt
   525  history
   526  hg branches
   527  hg branch
   528  hg up -r from1
   529  hg branch

hg branch foo

saves the name foo to be used as the branch name *starting* with the 
next commit.  I arbitrarily made that next commit a tag to identify the 
base of the new branch, and then made additional commits.

hg up -r foo

switches the working directory to the tip (head) of branch foo; "hg up" 
does all changing of location within the repo, regardless of whether the 
location is identified by a branch, a tag, etc.

hg branches

lists branches; with -a it omits closed branches.

One oddity you may notice in the example above is that the changeset 
resulting from the tag command is *after* the changeset that gets 
tagged.  Tags are just entries in a revision-controlled file, so the tag 
command changes that file, and then commits the change.  Any revision 
can be tagged at any time.

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

I would not be surprised if bookmarks were directly inspired by that. 
There is also a localbranch extension, but it is not included in the 
distribution and hasn't gotten much attention. I have the sense that 
bookmarks were designed to accomplish the same thing.


Eric