David Cournapeau wrote: > On Sat, Apr 11, 2009 at 6:16 AM, Eric Firing <efir...@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 _______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion