How to filter SVN log results by subdirectory of repo?

I am trying to use the SVN log command to find changes to files in a specific subdirectory/folder of my repo over a set of revisions.

Here is what I have so far:

The URL of my repo (trunk) is:

http://myserver/svn/repos/myproj/trunk

I only want to find modified/added files in the DB folder (or any subfolder of the DB folder) of the repo开发者_如何学JAVA:

http://myserver/svn/repos/myproj/trunk/DB

So far I have this:

svn log -r 300:351 -q -v --xml http://myserver/svn/repos/myproj/trunk/DB

When I run this, I get files in other parts of the repo, ie in the /trunk/app folder.

Is there a way to limit the results or do I have to do some post-processing?

I'm taking a punt here based on what you've described.

I suspect you're seeing paths other than the one you specified because those paths were affected by an action that was committed in the same revision as a change to the path you specified.

That being the case, you will need to post-process the XML in order to filter out the paths you don't care about.

Example: executing this command...

svn log -r 300:351 -q -v --xml http://myserver/svn/repos/myproj/trunk/DB

might result in output along the lines of this:

<?xml version="1.0"?>
<log>
<logentry
   revision="351">
<author>razlebe</author>
<date>2010-02-25T14:03:57.912308Z</date>
<paths>
<path
   kind=""
   action="D">/myserver/svn/repos/myproj/trunk/AnotherFolder
</path>
<path
   kind=""
   copyfrom-path="/myserver/svn/repos/myproj/trunk/AnotherFolder"
   copyfrom-rev="350"
   action="A">http://myserver/svn/repos/myproj/trunk/DB/AnotherFolder
</path>
<path
   kind=""
   action="D">http://myserver/svn/repos/myproj/SomethingElse</path>
</paths>
</logentry>
</log>

In this example, you're seeing a <logentry> element for revision 351. That revision included 3 actions:

• Deleting the folder /myserver/svn/repos/myproj/trunk/AnotherFolder
• Adding the folder http://myserver/svn/repos/myproj/trunk/DB/AnotherFolder
• Deleting the folder http://myserver/svn/repos/myproj/SomethingElse

So, the XML output includes a <logentry> for revision 351 because that revision affected your specified URL. But because that revision also affected other paths, those paths are described in the XML too.

In other words, the <logentry> describes the whole revision; not just the bit that affects the URL you specify.

When you take a verbose log of a particular directory in Subversion, and a revision also changes a file listed outside of that directory, that file will be listed.

I believe this is what is happening in your case. That is, there's a revision in a file or directory inside the http://myserver/svn/repos/myproj/trunk/DB directory that is also affecting a file in http://myserver/svn/repos/myproj/trunk/app. Thus, your log file will show both files changed in the revision.

One of the design considerations in Subversion was keeping all changes together in a single revision. In some other version control systems like Perforce, this would be considered a changeset and is the atomic constituent of a change. In other words, a change in Subversion is not a single revision of a file, but all the changes in all the files in a single revision.

In a certain sense, asking only for the changes in the DB directory would be meaningless and misleading. That's because a change in the DB also depended upon a change in the app directory too.

As others have suggested, you could filter the results of the XML file. (And if you do, I highly recommend you use a program module to do it (like XML::Simple if you're using Perl) instead of trying to parse it via regular expressions.

However, I recommend that you think about this before moving forward since you'll be breaking the atomic structure that Subversion uses for tracking changes. You might be giving a false notion of the change taking place. For example, if someone uses your report to back out a particular change in the DB directory, they might have to back out the change in the app directory too.

I think you have to do some post processing. I tried to get all changes to the root node only before and had to post process it. Linq-Xml makes the job pretty easy.