The attached patch adds tag support to mercurial targets. By the way,
it might be nice to give the tag operation the changeset context under
which it's being applied. It could be passed the changeset, or we
could pass a handle to the changeset to the commit operation and do
away with the separate tag pass...
New patches:

[Add tag support to mercurial target
Brendan Cully <[EMAIL PROTECTED]>**20051115100534] {
hunk ./vcpx/hglib.py 185
+
+    def _tag(self, tag):
+        opts = self._defaultOpts('tag')
+        commands.tag(self._getUI(), self._getRepo(), str(tag), **opts)
+
+    def _defaultOpts(self, cmd):
+        # Not sure this is public. commands.parse might be, but this
+        # is easier, and while dispatch is easiest, you lose ui.
+        return dict([(f[1], f[2]) for f in commands.find(cmd)[1][1]])
}

[Don't apply duplicate tags to mercurial targets
Brendan Cully <[EMAIL PROTECTED]>**20051116052626
 
 I just noticed that a CVS source will replay all of the tags that apply
 to HEAD on every run. This teaches mercurial to filter out equivalent tags
 (by checking whether they already exist in the commit history up to the last
 non-tag commit).
] {
hunk ./vcpx/hglib.py 187
+        """ Tag the tip with a given identifier """
+        # TODO: keep a handle on the changeset holding this tag? Then
+        # we can extract author, log, date from it.
hunk ./vcpx/hglib.py 191
-        commands.tag(self._getUI(), self._getRepo(), str(tag), **opts)
+
+        # This seems gross. I don't get why I'm getting a unicode tag when
+        # it's just ascii underneath. Something weird is happening in CVS.
+        tag = tag.encode(self.repository.encoding)
+        # CVS can't tell when a tag was applied so it tends to pass around
+        # too many. We want to support retagging so we can't just ignore
+        # duplicates. But we can safely ignore a tag if it is contained
+        # in the commit history from tip back to the last non-tag commit.
+        repo = self._getRepo()
+        tagnodes = repo.tags().values()
+        try:
+            tagnode = repo.tags()[tag]
+            # tag commit can't be merge, right?
+            parent = repo.changelog.parents(repo.changelog.tip())[0]
+            while parent in tagnodes:
+                if tagnode == parent:
+                    return
+                parent = repo.changelog.parents(parent)[0]
+        except KeyError:
+            pass
+        commands.tag(self._getUI(), repo, tag, **opts)
}

Context:

[Fix bzr incremental update
Brendan Cully <[EMAIL PROTECTED]>**20051114060007
 
 Incremental update in bzr isn't working: when tailor restarts it has no
 handle on the bzr branch object, and when it does a merge it doesn't
 make sure that it already has the changesets it needs. This patch
 introduces a getRepo method that gets a branch handle if there isn't one,
 and calls bzrlib.fetch.greedy_fetch to pull in all changesets before
 attempting to merge them.
] 
[Fix a last-second BPB converting revision names.
Brendan Cully <[EMAIL PROTECTED]>**20051114030337] 
[Mercurial source support via hglib
Brendan Cully <[EMAIL PROTECTED]>**20051114022602] 
[git commit fixes (date, # at end of commit message)
Brendan Cully <[EMAIL PROTECTED]>**20051114022122
 
 As of at least git 0.99.9e, git refuses to parse timestamps with
 microseconds such as str(datetime) may emit. This patch uses strftime
 to force the format to something simpler.
 
 It also manually duplicates GIT_AUTHOR_* to GIT_COMMITTER_* so that
 cg-log produces output most similar to the source log.
 
 git-commit expects the commit message to end with a newline, so this
 patch adds one if it isn't already there.
] 
[Ensure str() doesn't get handed a unicode changeset
Brendan Cully <[EMAIL PROTECTED]>**20051114021851
 
 I don't do a lot of python, so I may be misdiagnosing this bug, but I
 get a UnicodeEncodeError at Tailorizer.applyable on the debug line
 when tailorizing a source with non-ascii log messages on a UTF-8
 terminal. It appears that str() expects a __str__ function it calls to
 return a plain (not unicode) string. Could possibly be an OS X issue.
 
 The particular test was tailorizing the bzr repository from bzr to git
 or hglib, with changeset messages apparently in macroman, on a UTF-8
 terminal. This problem is made more annoying by the fact that bzr no
 longer seems to be able to resume (_b undefined in the upgrade path).
] 
[Ignore the backup copy of the state file
[EMAIL PROTECTED] 
[Fix cut&paste error
[EMAIL PROTECTED] 
[TAG Version 0.9.19 (retag)
[EMAIL PROTECTED] 
Patch bundle hash:
90431687f98334d2f555a3dffe212d68ad96af3f
_______________________________________________
Tailor mailing list
[email protected]
http://lists.zooko.com/mailman/listinfo/tailor

Reply via email to