Is the only way to list the “live” revisions of a particular SVN path “svn log -q -v” plus a filter?

Question

Is performing an "svn log -q -v" across all revisions against the repository root and then filtering by the desired path really the best (only?) way to do this? We need to find these ranges in order to provide peg revisions to an automated tool and to add supporting detail to our change reporting.

I have made a slight optimization to querying the root already:

Given a path:

protocol://server/repo/a/b/c/d/foo.txt

I've already written a script to perform repeated svn log queries up the path:

svn log -q -v .../a/b/c/d/foo.txt
svn log -q -v .../a/b/c/d
svn log -q -v .../a/b/c
svn log -q -v .../a/b
svn log -q -v .../a
svn log -q -v ...

until I don't get:

svn: File not found: ...

I have not run significant profiling tests, but it seems to me that the errors should be processed rather rapidly and the overall potential reduction in network traffic should outweigh the cost of the repeated queries in all cases except the one in which the repository root must be queried anyway.

The above doesn't work if the ancestor has multiple live ranges; unless someone knows better, my only option is to query from the repository root.

From the results, I essentially want the list of distinct ranges where the file exists (which I may later amend to also track history, such that a resurrected file has multiple ranges; as perverse as it may sound, we do have cases where files with the same path end up being unrelated). At the moment, I am parsing revision numbers as they pass, keeping track of the last revision of the desired path where it or one of its ancestors was deleted (initially HEAD, which will be overwritten if I see a delete). When I see that the path has been added, I dump out a range rev_added - rev_lastdeleted.

The above works, but it does involve traipsing through quite a bit of information, most of it spurious. Is there a more efficient way to do this, preferably one in which more work is done on the server side in order to minimize network traffic (a lot of our work is done remotely via VPN)?

It seems that the only way TortoiseSVN provides this same information is by performing the same process (get the log of an ancestor and then filter).

Answer 1

I don’t think so. If you want to format this data in a certain way, then you’ll have to take SVN’s output and process it like you’re doing.

The output from svn log filename should give you all the relevant revisions for filename — including its history of moves/renames — which you can then format however you want.