---%<---
$ hg clone -U http://selenic.com/repo/hg repo
requesting all changes
adding changesets
adding manifests
adding file changes
added 5793 changesets with 10852 changes to 790 files
$ hg -R repo tag whatever
$ hg -R repo log -l2
changeset: 5793:52ac65f4407b
tag: tip
parent: -1:000000000000
user: Jesse Glick <jesse.glick@sun.com>
date: Mon Jan 07 11:54:35 2008 -0500
summary: Added tag whatever for changeset 956e01c31914
changeset: 5792:956e01c31914
tag: whatever
user: Kevin Christen <kevin.christen@gmail.com>
date: Thu Jan 03 20:27:32 2008 -0600
summary: color extension: change from GPL3 to 2
---%<---
Note that the new revision containing the change to .hgtags is a child of the
null revision! Of course I wanted to commit it to the default branch as a child
of the tagged revision. If I ran the above command and neglected to verify the
result using hg log before pushing, the next person to do a (regular) clone will
see what looks like a busted repository:
---%<---
$ hg clone repo repo2
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ ls repo2
$ ls -a repo2
. .. .hg .hgtags
---%<---
If you do this, the fix is to run
---%<---
$ cd repo2
$ hg up -C -r5792
700 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ hg merge
merging .hgtags
# resolve conflict in merge tool...
0 files updated, 1 files merged, 0 files removed, 0 files unresolved
(branch merge, don't forget to commit)
$ hg ci -m fixed
$ hg log -l3
changeset: 5794:0297b2d17e56
tag: tip
parent: 5792:956e01c31914
parent: 5793:52ac65f4407b
user: Jesse Glick <jesse.glick@sun.com>
date: Mon Jan 07 12:15:48 2008 -0500
summary: fixed
changeset: 5793:52ac65f4407b
parent: -1:000000000000
user: Jesse Glick <jesse.glick@sun.com>
date: Mon Jan 07 11:54:35 2008 -0500
summary: Added tag whatever for changeset 956e01c31914
changeset: 5792:956e01c31914
tag: whatever
user: Kevin Christen <kevin.christen@gmail.com>
date: Thu Jan 03 20:27:32 2008 -0600
summary: color extension: change from GPL3 to 2
---%<---
which works but is a little subtle.
I would recommend that hg tag when run on a repository with no checked-out
revision behave in one of these ways:
1. Commit as a child of tip. (best IMO)
2. Abort with an error message, unless perhaps -f is used.
3. Accept a new parameter specifying the parent revision to commit from.
If desired, I can try to implement one of these options.
BTW the code in localrepo.py is confusing. _tag takes a 'parent' parameter, yet
this method is only called from one place (tag), which does not pass that
parameter (nor the 'extra' param). Reserved for future expansion, or should
self._tag be called with parent=tip if there is no checkout (i.e. fix #1)? |