Tagging Multiple files in SVN using commands

Question

I have a list of files with versions and file name like below,

1475|pet/dog/GetName.sh

1476|priceLogic/CheckdogPrice.sh

this is a just a small set and it can expand to a bigger number.

I want to tag them for a particular release and want to tag them using a single command in svn, otherwise I need to tag them one at a time.

I thought of using changelists but that will not help me carry the version number of the files.

Any suggestions?

Answer 1

Based on your question and your comments under David W's answer, let me restate what I think you are asking: For simplicity let's say you just released version 1.6 of your product and you did it properly, i.e. you created a 1.6 tag and all is well from there moving forward. But your team had not been following best practices and you do not have labels on version 1.5, version 1.4, or anything earlier and you foresee the need that you will inevitably need to go back to one or more previous revisions for bug fixes or other reasons.

My suggested course of action is this:

Identify the single revision number that represents release 1.5.

From your question I suspect you are not quite clear on the ramifications of this. If you commit file A at revision 128 and then commit file B at revision 129 then both files are now at revision 129. (Say you commit file A again, getting revision 130. Now if you rollback file A to revision 129 what do you get? The same file that existed at 128 when you committed it.) The figure attempts to illustrate this point. The tops of the bars represent the latest commit of each file and thus the head revision. This head revision consists of 128 for file A, 129 for file B, and 126 for file C. But this head revision is also revision 129. The point to grasp is that the current revision of a file does not have to (and usually does not) match the latest committed revision of a file. It is easiest to see this point when talking about the head revision but it applies equally well to earlier revisions. What constitutes revision 125? Well, it is when file A was committed at 124, file B at 125, and file C at 123. Thus for a given release, you must identify the revision at which all the latest commits are included.

Apply a tag to the identified revision number.

Once you identify a single revision number for release 1.5 use the svn branch/tag command specifying the identified revision number, rather than the head revision, as the target of the tag.

Repeat the above for each prior release that you want to tag.

Repeat, rinse, and wash, until done.

Complications

The above procedure should work most of the time. Sometimes, however, there are situations where you want to tag a mixed revision. Note that, per my example, 128 and 129 do not constitute a mixed revision. A mixed revision would be, for example, file A at 124 and file B at 127. You can tag a mixed revision by updating your working copy to that mixed revision, then creating the tag based on your working copy.

---

For more on this particular topic, you might also want to review part 6 of my TortoiseSVN and Subversion Cookbook published on Simple-Talk.com.

Answer 2

Please don't take this the wrong way, but there's a good chance you're not quite getting how things should be done in Subversion.

You should never be tagging a mishmash of missed match revisions. Subversion tagging should be based on a unified revision off of either some branch or off of trunk. Think of a tag as a snapshot of your repository at a certain point in time. In fact, many shops don't bother tagging, but instead simply use the Subversion revision number. ("Send revision 14485 to QA for testing").

The question is why do you need to do this. I can think of several reasons why people try to do sparse tagging:

• They want a list of the files that were modified. You can use the svn diff --summarize to do that.
• They have various versions of various files checked out in the workspace. In this case, you should be working off of a branch based upon a particular release, and have those changes placed in a branch.
• They're use to CVS and don't want to waste the time it takes to tag everything. In CVS, tagging cat take 30 to 40 minutes, maybe longer in a big repository. However, Subversion tagging is based upon a link to a particular URL and revision. Tagging in Subversion is quick and painless, so you simply tag everything.

So, if you let me know what you want to do, I might be able to guide you to a better way of doing this in Subversion.

Answer 3

There is no standard command way to read from your list and execute. You can easily tag if you had same versions for all files in your entire trunk.

What could be done is a small perl/bash script that could copy all the files from the list with respective revisions onto the common tag folder.