How to move a tag in SVN

Question

This question can be rephrased as:

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

A simple question, but I could not solve the problem myself.

The concept comes from other SCM tools, where you simply move the tag across different versions and “snap” it to the exact revision that you need. These other tools have their own understanding of what a tag is, where SVN generalized everything as a copy branch.

Below are the answers that I saw on other bulletin boards and posts on the same subject, and as such have already been considered and rejected:

• This is not a proper use of SVN
  • Actually, SVN was designed as a generic one and performs many usage patterns.
  • This is the mission to find the answer. I understand the problems, and the opportunity to never find the answer. Perhaps I will switch to another instrument.
• Why are you using SVN in this way, so it’s better to do this and that.
  • There are many usage patterns or SCM models that can be adopted. In my case in particular:
    • Trunk is an ongoing development, and minor fixes apply to it.
    • Production is one TAG
    • the turn from development is very short and aggressive, and therefore we cannot work with several full product releases. This means that I can’t create a new tag every time for every small substitution deployed during production.
    • So, in short, "The full batch release release does not exist in my scenario."
  • This is my use case. I need.

Well, I will not be presumptuous, and I will read every decision I provide and change my mind as necessary.

Answer 1

Tags and branches in SVN are no different. All the difference lies in the policies that follow the commands for working with tags and branches.

So, you can merge the changes into a tag and transfer the new revision in the same way as with the branch. It’s clear that usually you don’t want to do this in order to “tag” the exact versions of the files you used for release. But if it is really necessary, you can make an exception to this rule once.

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

Some links to the SVN book: " Tags ", " Branch Maintenance "

---

ADDED: So, it seems that such re-tagging is not a rare, atypical use case, but rather a common practice on your team. It seems that tags do not just give a name for a specific snapshot of your files, but they want this name to correspond to subsequent updates of files, forgetting about its previous place. It also seems that you will find branches inconvenient for your workflow.

Well, I don’t think there is a simple and clean way to achieve what you want with SVN. In my opinion, it is better to “hug” branches and learn how to use them effectively.

Answer 2

I found 1 easy way to do this (Ie move the tag for the file) using tortoise SVN.

• view your repo by right-clicking on the selected project directory and selecting "Tortoise SVN-> Repo-browser"
• Browse to the file you want to change in your tags / directory
• right-click on the file and select "checkout".
• Select a temporary directory on your HD and click OK.
• Overwrite this file with the updated version (using the local file accelerator, not the SVN repo browser)
• right-click on the file and select "SVN checkin".

The task is completed.

To do the same using CVS, it’s trivial, just go to the directory you want and type: “cvs tag -F tag file name” SVN really has no tags, which makes it painful to use (in my opinion).

Not sure why this was voted - this is how we solve the exact problem posed in the question.

Answer 3

Tags and branches in Subversion are really just directories. The concept of what they are is not built into Subversion, but your brain.

As others have noted, tags are snapshots of your repository at a particular point in time and should not change. If you plan to change the tag, it really should be a branch.

For instance,

• I want the tag to show approved changes: make it a branch instead of the tag.
• I want to show which files were used for the latest build: Ditto.
• I want to show which code was viewed: Ditto.

But these are not branches! you whine .

Well, the proposed repository structure is this: a sentence. You can add another directory besides trunk , tags and branches for these roaming tags:

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

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

I changed the proposed repository layout earlier in one place where I worked. I wanted to remove obsolete branches and tags from the repository, but management and developers objected.

I said that deleting these files does not delete it from the repository. I could easily return them if necessary, but by deleting them I removed a lot of unnecessary clutter from these two directories. However, the developers did not feel safe. Of course, I can find them, but can they?

Instead, I added the obsolete/tags and 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 were not cluttered, and managers and developers felt better so they knew that they needed to find these obsolete branches and tags if they were ever needed.

---

Say you are not doing anything with tags. You use tags as snapshots, and everything you expect to change and update is a branch. There are still moments when you need to change the tag.

And, Subversion does a better job of this than most other version control systems. This is because tags contain the entire history of their creation and changes. In most other version control systems, the history of this tag is a second-class citizen, even if it is preserved at all. You can see the tag. You can see which files and version are under this tag, but you cannot see who created this tag and how it was modified. Under Subversion, tags contain the whole story.

To make changes to the tag:

• Mark the tag.
• Make changes.
• Commit your changes.

Or, even better, use svn cp , svn mv or svn delete for the repository URL, not the working directory. For example, I created a tag for version 2.0. Suddenly, we realized that we had forgotten one very important change that was taking place in this release. Instead of checking, 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 the trunk. Then I see that the foo.java file was updated a week later from version 23933 on the trunk.

Answer 4

Your comment on @Alexey Kukanov's answer tells me that you really need a thread, not a tag. A tag is a historical record of a single, unchanging moment in time. A branch is a copy of the code that will undergo further changes over time. You are talking about the latter. The standard practice is to create "bugfix" or "production" branches for each version that you support, and either commit changes directly to the branch [1] or merge them with the trunk.

In this case, the tags will be used to create "copies" of the branch, to indicate "it was this code that was in production at this particular time." Thus, you can easily come back and compare with him if such a need arises.

[1] ... and then combine them into a connecting line, respectively

Answer 5

I also need to do this someday. What do you do, you check your svn file from a tag and not to a branch (so something like svn: // blahblah / tags / mytag, not svn: // blahblah / branches / mybranch), then you commit the changed file there, and he will have an updated tag.