[ANN] tagmerge - an extension for merging .hgtags

Greg Ward greg-hg at gerg.ca
Thu Feb 11 21:22:55 CST 2010


On Tue, Feb 9, 2010 at 2:15 AM, Qi Yang <qi.yang137 at gmail.com> wrote:
> For reading tags, what is the algorithm to store all the tags information?
> i.e. I know I can get tagname and tagnode through localrepo.tags() function.
> How can I get other informations like user, message, date etc? and how can I
> get the changeset stored in .hgtags file?

Once you have a changeset identifier in any form -- short hex, long
hex, binary, revision number, branch name, tag name, ... -- it's one
step a changectx object that reveals all: repo[rev] or repo[nodehex]
or repo[nodebin].  See http://mercurial.selenic.com/wiki/MercurialApi.
 Very very convenient.

However, for merging .hgtags, that's irrelevant.  You don't need to
know any of that stuff.  All you need is an algorithm that reads two
versions of .hgtags and merges them *while preserving order and
"duplicate" lines*, because order and duplicates matter.  They are
part of the .hgtags syntax.

> And what exactly is a "node"?

Usual convention in the Mercurial code is to use 'node' as the local
variable for the binary changeset ID of the changeset you're
interested in right now.  It's also used in lower levels (e.g.
manifest, filelog, revlog) to refer to any node in a revlog graph, not
necessarily a changeset.  (The changelog is a graph of changesets; the
manifest log is a graph of manifests; each filelog is a graph of file
revisions.  At each level, 'node' usually refers to a binary node ID.)

Likewise, 'rev' usually refers to an integer revision number.  Again,
it can be used at the changelog, manifest log, or filelog level.

And now you can forget about manifests and file logs.  They should be
irrelevant for merging .hgtags.  ;-)

Greg


More information about the Mercurial-devel mailing list