How can I mark a group of changes/changesets in SVN, Hg, or Git

Question

I would like to mark an arbitrary group of commits/changesets with a label.

• Commit 1 *Mark 1
• Commit 2 *Mark 2
• Commit 3
• Commit 4 *Mark 1
• Commit 5 *Mark 2

The goal is to easily locate all the changes for a specific mark, and to have that grouping persisted in the VCS directly, as opposed to some outside system like a bug tracking system.

The location and ordering of the marks needs to be arbitrary, and should be able to work with both committed/uncommitted and pushed/unpushed changes.

In SVN the best way I know is to just edit the commit notes and add some sort of special text that you can search for e.g. "**Mark 1". Or just to make a fake edit and commit it and use its commit note to list all the included revisions.

Is there a better solution for SVN? Are there equivalent or better solutions for Hg or Git?

Answer 1

For SVN you can use "SVN Properties" or the commit log messages. Check out this answer to a similar problem, and the feature request thread. If you use revision properties, to find the revisions with a specific value, you need to iterate through all the revisions, which in your case may be an issue regarding performance If you use the commit logs, you can use svn log and parse the output.

Ref: svn book Properties section

Answer 2

There is no special metadata with Git, beside the commit comment and date, or the tag.

So you are left with three choices:

• amending commit message to add some comment convention naming for a commit message
• trimming/squashing commits to update old commit messages, and clean up the history

Those two choices won't work well with commits already pushed.

The third choice is associate data to those commits, like a ticket. See ticgit for example of ticket bug tracking integrated to your git repo.

Answer 3

In mercurial you'd use a tag:

hg tag -r REVISIONNUMBER "MARK 1"

In all three systems you mention you're not going to be able to annotate "uncommitted ... changes".

It sounds like if you fully understood the branching options in either git or mercurial you'd probably abandon your notion of "groups of annotations", it's what branches do.

http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/