On Thu, Apr 15, 2010 at 3:42 PM, David Bartmess <dingod...@edingo.net> wrote:
> I need to modify a script that was used with CVS that basically got a list > of the files that changed with a specific tag, and acted upon them. Now > we're moving to Subversion, and I need a way to get a list of files that > changed with a tag or revision. > When Subversion tags a release, it does a link to the repository revision and directory you're tagging, so the operation is done within a second. Tagging does not increase the size of your repository and it doesn't matter if you're tagging one file or a million files -- tagging is done in a second. However, despite the fact that tagging is quick and painless, many sites don't bother with tagging each and every build. (They still tag releases). The main reason is that build tags clog up the tags directory and make it difficult to see the release tags (which are more important). We tag every build, so I put build tags into the tags/DEV directory and put release tags into the tags/REL directory. That way, my daily build tags (and we sometimes have a half dozen builds each day) don't make it difficult to find the release numbers. You can find out all the files changed between two tags via: $ svn diff --summarize http://path/to/proj/tags/REV-1.0 http://path/to/proj/tags/REV-1.2 I just tested it to make sure. If you want to see the commit messages between two releases, you'll need to know what the repository revision number was for each release. You can use this command: $ svn log --stop-on-copy -v http://path/to/proj/tags/REV-1.0 ------------------------------------------------------------------------ r61030 | dweintraub | 2010-03-06 20:56:16 -0500 (Sat, 06 Mar 2010) | 1 line Changed paths: A /proj/tags/REL-1.0 (from /proj/trunk:61029) >From here, you can see that the tag REL-1.0 was from the trunk, repository revision 61029. Once you get the revision numbers of both tags, you can do a log between the two repository revisions: $ svn log -r61029:63392 http://path/to/proj/trunk And, see what the commit messages were. It's not 100% straight forward, but we used CVS and switched to Subversion and I had to do a lot less processing with Subversion to get the reports I wanted. -- David Weintraub qazw...@gmail.com