views:

500

answers:

4

In my subversion repository, I have the standard /trunk, /branches and /tags folders and a tag, say /tags/tag1.

Is it possible to checkout /tags/tag1, make some local changes, and then commit directly as another tag, say /tags/tag2? Can I do this without touching the trunk or any branches?

Also, if this is generally possible using subversion, can it be done with TortoiseSVN?

Edit:

If this can be done using TortoiseSVN, I assume it can be done from the command line. What commands would I need to use?

+3  A: 

Yes, you can do this: checkout the tag, then fro the working copy choose Branch/Tag and select "Working copy" in the "Create copy in the repository from:" section, and in the "To URL:" field enter the url of the new tag.

But why you want to do this? Usually, tags are "read-only" snapshots of the state of the code base, and should not be modified.

Davide Gualano
Why? I want to make a small change to the code under an existing tag, and then be able to refer to my changed code using a (new) tag. For a single small alteration, I feel that creating a branch from the tag, making the changes and then tagging the branch is overly complex.
Paul Baker
BTW, I agree that tags should not be modified - that's why I want to commit my change as a new tag, rather than commiting again under tags/tag1.
Paul Baker
Usually, you tag the codebase from a branch or from the trunk, so, to make the small change, you modify the working copy of the trunk or the branch and create the tag from there. But of course there is not a "right way" to do the things, so your choice is perfectly acceptable.
Davide Gualano
It seems to me that there are two scenarios in which modifying "the working copy of the trunk or the branch" will not work. Firstly, where the trunk or branch has moved on since the tag was made - we don't want the changes to the trunk/branch to be in our new tag. Secondly, the reverse: what if we don't want the changes to our new tag to be on the trunk/branch? In these cases, as far as I can see the only alternative to my proposed method is to create a new branch from the tag.
Paul Baker
There are of course lots of possible scenarios in which your observations are valid. If you haven't already done, I would like to suggest you this chapter of the SVN Book which shows two common and very useful strategies to use branches and tags: http://svnbook.red-bean.com/nightly/en/svn.branchmerge.commonpatterns.html I hope this could be useful in some way :)
Davide Gualano
A: 

You can create a branch from /tags/tag1 to /tags/tag2. You can do this without touching the trunk or any existing branches.

We call this hotfix branching, because /trunk has moved on, but there's something in /tags/release-1.0 that needs to be fixed. So we'll branch from /tags/release-1.0 to /tags/release-1.0.1. We'll make the fix and commit to that tag.

Jarrett Meyer
A: 

Subversion basically treats everything like a directory structure - a tag is simply another folder in the structure that happens to be within a 'tags' directory.

Thus, technically you could check out the tags directory, copy one tag folder to a new folder, svn add that new folder, and commit it - which would essentially create a new tag based off of the old files. However, you wouldn't get the link between the old tag and the new one (which sort of makes sense - tags aren't supposed to be linked to anything, they're just supposed to be snapshots).

A better scenario if you want good progression of revisions would be to copy the old tag into a branch; make the changes, commit the branch, and then copy the branch back to a new tag. This would preserve the history of the changes much more accurately.

Amber
+1  A: 

It is possible to do this from TortoiseSVN. Go to the location of the tag that you locally modified in Windows explorer. Choose 'Branch/ Tag' from the TortoiseSVN context menu. Now select the TO url to something like 'svn://server/project/tag2'. Next, for 'Create copy in the repository from', choose the option 'Working Copy'

CruiZen