ChatGPT解决这个技术问题 Extra ChatGPT

How to properly create an SVN tag from trunk?

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"
Unfortunately I don't make all the choices in this case... git is pretty damn magic.

D
Dave Jarvis

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"

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)."
I get svn: Local, non-commit operations do not take a log message or revision properties, so I just remove the -m option.
Just an FYI, make sure that your url matches your repository including http or https.
Why the \ at the end of the first line?
@Jonny I am unable to run the above command without the "-m" option. I am using terminal on mac.
u
unwind

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.


files copied does not spend any extra space
A
Alexander Amelkin

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.


It is possible to use "Last Changed Rev": echo "{ 'svnRev': \"`svn info | awk '/Last Changed Rev:/{print $4}'`\" }" >svnver.txt `
This way, two branches with (of course) different revision numbers still produce the same software version.
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.
@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
@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.
G
Gromer

Could use Tortoise:

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


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

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


Can you elaborate how it should look like if i only checkoput from trunk and i'm inside with my script.
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.
How is this answer different from the accepted one?
C
Community

@victor hugo and @unwind are correct, and victor's solution is by far the simplest. However BEWARE of externals in your SVN project. If you reference external libraries, the external's revision reference (whether a tag, or HEAD, or number) will remain unchanged when you tag directories that have external references.

It is possible to create a script to handle this aspect of tagging, for a discussion on that topic, see this SO article: Tagging an SVN checkout with externals


A
Alexander Amelkin

Another option to tag a Subversion repository is to add the tag to the svn:log property like this:

   echo "TAG: your_tag_text" > newlog
   svn propget $REPO --revprop -r $tagged_revision >> newlog
   svn propset $REPO --revprop -r $tagged_revision -F newlog
   rm newlog

I recently started thinking that this is the most "right" way to tag. This way you don't create extra revisions (as you do with "svn cp") and still can easily extract all tags by using grep on "svn log" output:

   svn log | awk '/----/ {
                      expect_rev=1;
                      expect_tag=0;
                  }
                  /^r[[:digit:]]+/ {
                      if(expect_rev) {
                          rev=$1;
                          expect_tag=1;
                          expect_rev=0;
                      }
                  }
                  /^TAG:/ {
                      if(expect_tag) {
                          print "Revision "rev", Tag: "$2;
                      }
                      expect_tag=0;
                  }'

Also, this way you may seamlessly delete tags if you need to. So the tags become a complete meta-information, and I like it.


A
Ashu
svn copy http://URL/svn/trukSource http://URL/svn/tagDestination -m "Test tag code" 
  $error[0].Exception | Select-object Data

All you have to do change URL path. This command will create new dir "tagDestination". The second line will be let know you the full error details if any occur. Create svn env variable if not created. Can check (Cmd:- set, Powershell:- Get-ChildItem Env:) Default path is "C:\Program Files\TortoiseSVN\bin\TortoiseProc.exe"


P
Peter Mortensen

Try this. It works for me:

mkdir <repos>/tags/Release1.0
svn commit <repos>/tags/Release1.0 
svn copy <repos>/trunk/* <repos>/tag/Release1.0
svn commit <repos/tags/Release1.0 -m "Tagging Release1.0"

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).