How to move a Tag in SVN

Question

This question can be rephrased as:

How can I include a single change in the trunk of a specific file into an existing TAG.

A simple question, but one I was not able to resolve to satisfaction myself.

The concept comes from other SCM tools, where you just move a tag over the different revisions and "stick it" to the exact revision you need. Those other tools have the native understanding of what a Tag is, where SVN generalized everything as a copy-branch.

Below answers I have seen on other bulletin boards and posts on this same, and as such were already considered and rejected:

1. This is not the proper use of SVN
   • Actually, SVN was designed to be generic, and accomplish many use patterns
   • This is a mission to find an answer. I understand the challenges, and the possibility of never finding an answer. Maybe I will switch to a different tool.
2. Why are you using SVN such our so, it is better to do this and that.
   • There are many use patterns or SCM models that can be adopted. In my case specifically:
     • The Trunk represents ongoing development, and small patches are applied to it.
     • Production is a single TAG
     • the turn-around from development is very short and aggressive, and as such we cannot work with several complete production releases. That means I can not every-time create a new tag for every little sub-change deployed in production.
     • So in short "Complete Packaged Production releases do not exist in my scenario".
   • This is my Use case scenario I need.

Well, I wont be presumptuous, and I will read every single solution provided and reconsider as needed.

Answer 1

I also need to do that sometime. What you do you check out your svn file from the tag, not the branch (so something like svn://blahblah/tags/mytag, not svn://blahblah/branches/mybranch), then you commit the changed file in there, and it will have the updated tag.

Answer 2

I have found 1 easy way to do this (I.e. move a tag for a file) using tortoise SVN.

1. browse your repo by right clicking on your checked out project dir and selecting "Tortoise SVN->Repo-browser"
2. Navigate to the file you want to change within your tags/ directory
3. right click on the file and select "checkout".
4. Select a temporary directory on your HD and hit ok.
5. Overwrite this file with your updated version (using your local file exporer, not the SVN repo browser)
6. right click on the file and select "SVN checkin".

Job Done.

To do the same thing using CVS is trivial, just go to the required directory and type: "cvs tag -F tagname filename" SVN doesnt really have tags, which makes it painful to use (In my opinion).

Not sure why this has been down voted - it is how we solve the exact problem set in the question.

Answer 3

Tags and branches in Subversion are really just directories. The concept of what they are isn't embedded in Subversion, but your brain.

As others have stated, tags are snapshots of your repository at a certain point in time, and should not be changing. If you plan on changing a tag, it really should be a branch.

For example,

• I want a tag showing the approved changes: Make it a branch instead of a tag.
• I want to show what files have been used for the last build: Ditto.
• I want to show what code has been reviewed: Ditto.

But these aren't branches! you whine claim.

Very well, the suggested structure of a repository is just that: A suggestion. You could add another directory besides trunk, tags, and branches for these moveable tags:

$repo/trunk
$repo/branches
$repo/tags
$repo/moveable_tags

Now, you can put the tags you change under moveable_tags, and the tags that people use for releases, snapshots, etc. under tags.

I've modified the suggested repository layout before at one location where I worked. I wanted to delete obsolete branches and tags from the repository, but management and the developers objected.

I said that deleting these weren't deleting it from the repository. I could easily get them back if needed, but by removing them, I eliminate a lot of unnecessary clutter from these two directories. However, the developers didn't feel secure in this. Sure, I can find them, but can they?

Instead, I added an obsolete/tags and an obsolete/branches directories to the trunk, tags, and branches directory level. Instead of deleting obsolete tags and branches, I just moved them. tags and branches weren't cluttered, and the managers and developers felt better that they knew were to find these obsolete branches and tags if they ever needed them.

---

Let's say that you're not doing anything fancy with tags. You use tags as snapshots and anything you expect to be changed and updated is a branch. There are still times when a tag might need to be changed.

And, Subversion is better at handling this than most other version control systems. That's because tags contain the entire history of their creation and changes. In most other version control systems, the history of that tag is a second class citizen if it is even kept at all. You can see the tag. You can see what files and version are under that tag, but you can't see who created that tag and how it had been changed. Under Subversion, tags contain their entire history.

To make a change in a tag:

• Check out the tag.
• Make the change.
• Commit your change.

Or, even better, use svn cp, svn mv, or svn delete against the repository URL and not against a working directory. For example, I created a tag for release 2.0. Suddenly, we realized we forgot one very important change that's going out in this release. Instead of a checkout, you do this:

$ svn cp -r 23933 -m"This change in this file should have been included in the tag" \
    $repo/trunk/foo/src/foo.java $repo/tags/2.0/foo/src/foo.java

When you look at the history of this tag, you will now see.

 $svn log -v $repo/tags/2.0
 ------------------------------------------------------------------------
 r23945 | david | 2013-04-03 11:21:55 -0400 (Wed, 3 Apr 2013) | xxx lines
 Changed paths:
 M /tags/2.0/foo/src/foo.java (from /trunk/foo/src/foo.java:23933)

 This change in this file should have been included in the tag

 ------------------------------------------------------------------------
 r23932 | david | 2013-04-10 11:18:40 -0400 (Wed, 10 Apr 2013) | 1 line
 Changed paths:
 A /tags/2.0 (from /trunk:23921)

 Created release 2.0

I see that the tag was created a week ago from revision 23921 on trunk. Then I see that the file foo.java was updated a week later from revision 23933 on trunk.

Answer 4

Your comment on @Alexey Kukanov's answer indicates to me that what you really want is a branch, not a tag. A tag is historical record of a single, unchanging point in time. A branch is a copy of the code that will undergo further changes as time goes on. You're talking about the latter. It's standard practice to create "bugfix" or "production" branches for each release that you're supporting, and either commit changes directly on the branch[1] or merge them from the trunk.

Tags, in this case, would be used to create "copies" of the branch to indicate "exactly this code was in production at this particular time". So you can easily go back and compare against it if the need arises.

[1] ... and later merge them to the trunk as appropriate

Answer 5

Tags and branches do not differ in SVN. All the difference is in policies that teams follow for how to work with tags and branches.

So you can merge changes into a tag and commit a new revision the same way you would do it with a branch. It's understandable that usually you don't want to do that, in order to "tag" the exact versions of files that you used for a release. But if it is really required, you can make an exception from this rule once.

Alternatively, you can remove the tag, and then re-create it using the right revision(s).

A couple of links to the SVN book: "Tags", "Branch Maintenance"

---

ADDED: So, it sounds that such re-tagging is not a rare, untypical use case but rather a regular practice in your team. Seems with tags you do not just give a name to a particular snapshot of your files, but want that name to follow subsequent updates of the files, forgetting its previous place. Also it seems you find branches inconvenient for your workflow.

Well, I do not think there is a simple and clean way to achieve what you want with SVN. In my opinion, it's better to "embrace" branches and learn how to use them efficiently.