Commits that modify svn tags appear in both tag and default

Issue #404 resolved
Zane Purvis created an issue

If someone commits to an svn tag, when that commit is pulled by hgsubversion, it appears on both default and the tag "branch".

For an example of a repo that exhibits this behavior see: http://zdp-hgsubversion-test.googlecode.com/svn/

The hg log appears as below. Notice that rename "binaries" to include version number in filename appears twice even though it was made using svn to the tag "branch."

Where I work, we keep binaries in SVN, and after we tag a build, the binaries are renamed to include the filename. I know that a tag should be immutable, but this practice is not something I can change.

$ hg log -G
@  changeset:   5:d898803f4013 [public, 6]
|  tag:         tip
|  user:        Zane.Purvis@a5f26265-be8f-10b2-26cb-344c91c08d71
|  date:        Tue Aug 06 17:27:16 2013 +0000
|  summary:     A change to describe what happened over on tag v1
|
o  changeset:   4:905a1a5f8333 [public, 4]
|  parent:      2:3e723d5ef439
|  user:        Zane.Purvis@a5f26265-be8f-10b2-26cb-344c91c08d71
|  date:        Tue Aug 06 17:26:11 2013 +0000
|  summary:     rename "binaries" to include version number in filename
|
| o  changeset:   3:b2aff12eca29 [public, 5]
| |  tag:         v1
| |  parent:      1:388d317fbf90
| |  user:        Zane.Purvis@a5f26265-be8f-10b2-26cb-344c91c08d71
| |  date:        Tue Aug 06 17:26:11 2013 +0000
| |  summary:     rename "binaries" to include version number in filename
| |
o |  changeset:   2:3e723d5ef439 [public, 4]
|/   user:        Zane.Purvis@a5f26265-be8f-10b2-26cb-344c91c08d71
|    date:        Tue Aug 06 17:25:30 2013 +0000
|    summary:     Tag v1
|
o  changeset:   1:388d317fbf90 [public, 3]
|  user:        Zane.Purvis@a5f26265-be8f-10b2-26cb-344c91c08d71
|  date:        Tue Aug 06 17:24:35 2013 +0000
|  summary:     Prep for tag of v1
|
o  changeset:   0:f4f5316a4a9e [public, 2]
   user:        Zane.Purvis@a5f26265-be8f-10b2-26cb-344c91c08d71
   date:        Tue Aug 06 17:21:06 2013 +0000
   summary:     Initial commit

The desired behavior would be for the changeset to appear only on the branch that leads up to the tag.

Comments (6)

  1. Augie Fackler repo owner

    I'm afraid we can't fix this, because we need the .hgtags file to exist in as few places as possible. If we didn't, there could be some weird edge cases with tags being unstable between versions depending on the topology of the resulting hg repository, which would really stink.

  2. Zane Purvis reporter

    Hmmmm.

    git-svn uses branches instead of tags to deal with SVN's mutable tags. Would such an approach work here? Maybe a --tags-as-bookmarks option during the clone operation to opt in to using branches if dropping the existing hgsubversion tagging behavior is undesirable.

  3. Augie Fackler repo owner

    I could sort of see a config knob to deal with this (not a documented flag), but I'm a little curious why you think that'd be an advantage over having them really appear to be hg tags?

  4. Zane Purvis reporter

    If they were lightweight-branches/bookmarks instead of hg tags, the .hgtags file would not be involved at all, and there would be no loss in functionality in hg. Then, if an svn user committed a change to an svn tag, it would appear to a hgsubversion user as an update to the bookmark named svn-tag/<svn-tag-name>

    Having svn tags be bookmarks in hg also helps to mirror svn's treatment of tags as just specially-named branches.

  5. Zane Purvis reporter

    Why would there need to be more than one .hgtags file to make the changeset only appear on the branch leading to the tag?

  6. Zane Purvis reporter

    If the commit message for the changeset that did nothing but update the .hgtags file said something along the lines of "Update svn-tag B1.03" instead of duplicating the commit message from the SVN tag, it would be more obvious what is going on, and less confusing.

  7. Log in to comment