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"
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.
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.
Could use Tortoise:
http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug-branchtag.html
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With