How to properly create an SVN tag from trunk?

Question

I am creating my first project in Subversion. So far I have

 branches
 tags
 trunk

I think I immediately need to make branches singular and start over. Update branches is the norm.

I have been doing work in trunk and moving the contents to tags as follows.

mkdir tags/1.0
cp -rf trunk/* tags/1.0
svn add tags/1.0
svn commit -m " create a first tagged version"

My gut tells me this is totally wrong, and I should maintain some relationship between the files using svn copy. The files I create in this way will have no relationship to each other, and I am sure I will miss out on Subversion features. Am I correct?

Should I use svn copy for the individual files?

mkdir tags/1.0
svn add tags/1.0
svn copy trunk/file1 tags/1.0
svn copy trunk/file2 tags/1.0
svn copy trunk/file3 tags/1.0
svn commit -m " create a first tagged version"

Should I use svn copy on the entire directory?

svn copy cp -rf trunk tags/1.0
svn commit -m " create a first tagged version"

Solution 1

You are correct in that it's not "right" to add files to the tags folder.

You've correctly guessed that copy is the operation to use; it lets Subversion keep track of the history of these files, and also (I assume) store them much more efficiently.

In my experience, it's best to do copies ("snapshots") of entire projects, i.e. all files from the root check-out location. That way the snapshot can stand on its own, as a true representation of the entire project's state at a particular point in time.

This part of "the book" shows how the command is typically used.

Solution 2

Use:

svn copy http://svn.example.com/project/trunk \
      http://svn.example.com/project/tags/1.0 -m "Release 1.0"

Shorthand:

cd /path/to/project
svn copy ^/trunk ^/tags/1.0 -m "Release 1.0"

Solution 3

As noted by @victor hugo, the "proper" way is to use svn copy. There is one caveat though. The "tag" created that way will not be a true tag, it will be an exact copy of the specified revision, but it will be a different revision itself. So if your build system makes use of svn revision somehow (e.g. incorporates the number obtained with 'svn info' into the version of the product you build), then you won't be able to build exactly the same product from a tag (the result will have the revision of the tag instead of that of the original code).

It looks like by design there is no way in svn to create a truly proper meta tag.

Solution 4

Could use Tortoise:

http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug-branchtag.html

Solution 5

Just use this:

svn  copy  http://svn.example.com/project/trunk  
           http://svn.example.com/project/branches/release-1
           -m  "branch for release 1.0"

(all on one line, of course.) You should always make a branch of the entire trunk folder and contents. It is of course possible to branch sub-parts of the trunk, but this will almost never be a good practice. You want the branch to behave exactly like the trunk does now, and for that to happen you have to branch the entire trunk.

See a better summary of SVN usage at my blog: SVN Essentials, and SVN Essentials 2

View more solutions

Comments

[ojblass]

Unfortunately I don't make all the choices in this case... git is pretty damn magic.

[ojblass]

I am going to build a larger system on top of this so I need to focus on the core functions provided.

[granadaCoder]

I marked this as answer. Just one extra note. You can get an previous revision of the trunk and "tag" it as well. the command: svn copy -r 123 "svn.example.com/project/trunk" "svn.example.com/project/tags/1.0" -m "Tagging, but using older revision (123)."

[Carlos]

files copied does not spend any extra space

[18446744073709551615]

It is possible to use "Last Changed Rev": echo "{ 'svnRev': \"`svn info | awk '/Last Changed Rev:/{print $4}'`\" }" >svnver.txt `

[18446744073709551615]

This way, two branches with (of course) different revision numbers still produce the same software version.

[Jonny]

I get svn: Local, non-commit operations do not take a log message or revision properties, so I just remove the -m option.

[Alexander Amelkin]

Yes, you're right about Last Changed Rev, but that doesn't change the fact that by design there are no real tags in Subversion.

[Norman H]

Just an FYI, make sure that your url matches your repository including http or https.

[vault]

i did: svn cp trunk tags/1.0.0; svn ci tags/1.0.0 -m "Release 1.0.0"

[Alexander Amelkin]

This is definitely a wrong way to go. The tag (Release1.0) should be a copy of the source directory (trunk), not an arbitrarily created directory. If you do it the way you did, you lose history of the source directory itself and only keep history of descendant nodes (files and directories).

[Fractaliste]

Why the \ at the end of the first line?

[aholbreich]

Can you elaborate how it should look like if i only checkoput from trunk and i'm inside with my script.

[AgilePro]

If you have checked out the trunk folder, then you need to use the http address of the repository. I have updated the answer to represent this since checking out the trunk folder is the recommended pattern.

[Luchostein]

@18446744073709551615: You can avoid using awk and obtain that information straight from svn using the --show-item option: svn info --show-item last-changed-revision

[Abdurrahman Mubeen Ali]

@Jonny I am unable to run the above command without the "-m" option. I am using terminal on mac.

[Surely]

another note from git user: after the command, it will only create the new tag on server. You have to "svn update" to pull the new tag to local, in order to "see" the new tag in your machine. For the paths, you can navigate to the corresponding branch folder and use "svn info" to get it.

[Daniel W.]

How is this answer different from the accepted one?

[Tom]

svn: E160013: '/!svn/rvr/2156121/trunk' path not found

[Wolf]

@Fractaliste the backslash character (`\`) is for line continuation

[Wolf]

@AlexanderAmelkin the tag is only used for its property to create an atomic storage of time and place (revision + folder). You never need to checkout a tag for a working copy, you use the one-point history of the tag to get its real content. I hope my wording isn't confusing to you. I mostly use the photograph metaphor: the tag is the photo, the trunk or branch (portion) at the time the photo was taken is the content you are interested in. Since the photo itself is contained in the repo, it has its own time and place.

[Nabakamal Das]

For users getting the svn: E205009: Local, non-commit operations do not take a log message or revision properties error, use double quotes v/s single ones when using the "-m" option.