>>>
>>> e.g. the Vim 7.3.000 candidate(s?) named above
>>> $ hg tag -r ee53a39d5896 v7-3-000
>>> $ hg tag -r 2a2ad267db08 v7-3-000
>>
>> Obviously you only do one of those. Hg doesn't have any weird
>> multiple/indeterminate tagging thing (thankfully!) :-)
>
> Sure. I just wasn't sure why the original poster posited two different
> revisions as the correct v7-3-000. I guess they're treesame (checking
> either out would result in an identical file+directory structure)?
Yes.
> ...but with different histories?
History is the same, too.
> (A remnant from the "combine two branches" thing that happened?)
Possibly. I don't know what that thing was. But it is branch-related.
Basically the vim73 branch was closed and turned into the default branch
by revision 2a2ad267db08. So ee53a39d5896 is the last revision on the
vim73 branch, and its only child, 2a2ad267db08, is the same tree on the
default branch. 'Branch' is an unfortunate name for what Mercurial
actually supports in this regard, as it's not really a branch of
anything, necessarily--it's like a permanent tag stored with a changeset
such that checking out that tag checks out the latest changeset having
it. I think it would be better to tag 2a2ad267db08, since it's on the
default branch where development is now taking place, so any new
changesets based on v7-3-000 should be put on that branch, not on the
vim73 branch which had development leading up to 7.3. But it probably
doesn't matter anyway--who's going to base a changeset on 7.3.000 now
anyway?
Ben.
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
No comments:
Post a Comment