SVN log of a fixed path across copies and moves

I'm trying to get the log history (recursively, if possible) of a fixed path in SVN across all copies/moves/etc. Effectively, I'm trying to avoid peg revisions, and have the log apply to the path rather than the objects. The svn manual poses this question - "Are you asking about the operatio开发者_JAVA百科ns that have happened to all the objects that have ever lived at that path?" - but it does not seem to provide an option for this use case. It assumes that this is not what you want, but this is exactly what I want.

Is there a way to do this without issuing repeated queries to cross the gaps between different copies living at a fixed path across the SVN revision history?

I don't know of any way within SVN. All the history seems to be from the object's perspective, not the repository's perspective. Even doing it by stitching together multiple requests would be a challenge because you have to figure out when an object moved and you should make a new request.

The best I can think of would be to get the complete history from the repository root, and filter that looking for changes that affected the path you're interested in. That could be expensive for a large repository.

After consulting with SVN developers, the answer to this question is that it is not possible with a single svn command. There is a very old bug open to implement this behavior, but it has not gotten traction:

http://subversion.tigris.org/issues/show_bug.cgi?id=928

Hopefully this will be possible in a future release.

Another way may be to write custom hooks for your repository. When there is a commit to a certain path you can record it in a log.

Use ViewVC with the "commit database" feature. It will extract metadata about every commit into a SQL database. You can then query the SQL database for all commits that affected a specific path.

The initial metadata extraction takes a long time - about 12 hours for a 10GB repository - but only has to be done once. Then you can set up a post-commit hook to update the metadata on every commit, which is fast. The metadata database is medium-sized - about 200MB for a 10GB repository.

Querying the metadata is fast.