RSSSubversion needs “named revisions”
Jul 12
Development subversion, svn Comments Off
As I mentioned in my last post, “tags” in subversion is a hack. A copy of a directory sitting in /tags that is still writable is simply NOT what I need when I need to “tag” (remember) a revision (a release, merge point, or a vendor drop for example).
Playing with git, the two things I liked the most about the day-to-day development features were proper branching and merging, as well as tagging. Subversion, in the latest release, is getting near to having proper merge support.
But it still lacks “tags”, “labels” or whatever you want to call them. The most descriptive name would be simply “named revision”. Here’s a simple (perhaps naive) implementation idea.
Assume a tag is simply a named revision. Since revisions are global, so are tag names (vs. being tied to a specific directory … which could be implemented but adds additional, unneeded complexity to the implementation).
This would seem trivial to implement, and could probably be done with a “wrapper script”, that simply does a search and replace on the subversion command before sending it to subversion. I haven’t looked at hacking subversion itself ….
assume::
tags.txt could contain:
release-1.0.0: 29
release-1.1.2: 33
release-stable: 33
Then whenever a command takes a revision, just search and replace:
I type: svn co http://svn.intelliforge.net/svn/
subversion sees: svn co http://svn.intelliforge.net/svn/
Similarly, you don’t manually “remember” revisions for creating patches, merges or whatever:
I write: svn diff -r release1.0.0:release-1.1.2
subversion sees: svn diff -r 29:33
I’d propose one new command (or a seperate tool). In this trivial implementation, the tag command simply manipulates the tag.txt file, and checks it back in.
svn tag [-f] [-r] [-d] [name]
svn tag simply lists the tag names and associated revisions (svn cat
svn tag tagname associates the current revision with a tagname, where “-r” specifies a specific the revision,
“force” would overwrite / move a tag name, and “-d” deletes the tag if you want.
You could even specify -m for the commit message, if you wanted to keep “tags.txt” logfile current.
If a tag name exists, an add would fail with a warning unless -f is passed – in which case the old tag is deleted and a new one created (basically a “move”). Note that since tags.txt is, itself, versioned, you could conceivably get a list of all tags over time …
For a native implementation, you’d just have to patch the svn libs so that -r can take a numeric revision or a text label, and do the appropriate lookup.
I’m sure the people who live and breathe subversion can find an appropriate way to implement this or something similar.
Any takers?