How do I move tags in Subversion

Question

I wish Subversion had a better way of moving tags. The only way that I know to move a tag is to remove the file from the tag and then copy it again. Revision tree browsers don't seem to handle that very well. This also requires keeping the directory structure under the trunk and tag in sync.

Use case: We have thousands of "maps" and we want to tag which version of each map is the "production" version. We need to be able to easily get the production version of all maps.

Can anyone suggest a better way to address our use case? I have considered properties also but then we can't get the prod version of all files easily. Merging to the tag doesn't appear to be very easy either. (Originally posted to http://jamesjava.blogspot.com/2007/12/subversion-moving-tags.html)

Answer 1

I don't see the need to "remove" the file from the production tag. You should copy the new file over the existing one and check it in. That way you will preserve the history.

Of course you would need the production tag checked out to do this.

Answer 2

I don't think you can ever do this with the way that subversion operates. I believe the best solution would be to look at a tool like git which seems like it fits into your use case. You're production system could 'pull' in the "maps" that are accepted. While I realize this isn't subversion, using git might be closer match to your use pattern than svn.

A really good write up on why git's pull based development model is a better match to your scenario is here.

There are also tutorials on how to start migrating like this.

Answer 3

Why don't you make a new tag for the current production version? Remember, Subversion is not CVS. So making a copy of the complete directory tree doesn't cost you anything.

Answer 4

This is not a good use for subversion.

Subversion tags are for giving a name to an instance of a tree as at a specific snapshot in its history, and should be kept static.

Perhaps you could use the current date, or an incrementing number as part of the tag? you could have a directory under tags containing the production versions as at any particular date. Take the latest date as the current production version.

Today's version could be found at

/svn/tags/production/2008/09/15/mapproject

Answer 5

One way would be to move to a "stable trunk" model.

• Make a branch from trunk to use as your working area.
• Stop making commits directly to trunk - have everyone switch to the development branch.
• Have trunk checked out by the people who are managing stable releases, ensure they have commit rights.
• When you wish to "release" a map, use "reintegrate merge" to pull in the changes to that file/directory and commit the changes.

This might appear a bit upside down but is fairly workable. You can either have production machines pull straight from trunk, or make a new tag from trunk for each release. For the latter, you will need some way to communicate the new tag to the production machines. Some sort of messaging, shared config or naming convention could work.

But be aware that you must get into the mindset of trunk being somewhat 'sacred' in this model.

Answer 6

If i understand well your needs, i think that the best way of doing it, is to have all maps as externals of the main trunk and then make a script that recursively tags each map (external) to it's current revision in the working copy (or the server if you want it that way).

Answer 7

I think you are trying to solve the wrong problem.

It sounds like you have a trunk which contains versions of maps which are not yet released, and when you do a release, you want to cherry pick which maps to update from all the possible updates on trunk.

Assuming this is the case, create a branch called "Release". (Consider creating a new empty directory, and copying each map version needed (with separate svn cp commands) if that will be faster).

Now you have the current release in the branch. Tag it (svn cp the whole directory) with "Release XXX" where XXX is the meaningful ID for your latest release.

Then as maps are approved for the next release, svn cp them to your release branch. I assume you don't want to use merge, because maps a discrete elements not source code.

At the time of the next release, you can tag again.

Now you know, what the latest approved maps are and what was in every release. If you really can't remember the latest release number, and you can come up with a time you'd need to know without just looking in the tags directory, you can create a tag which svn cp the latest release, then blow it away and re-copy when you do the next release.