ansaurus

Only for a particular peg revision; if I add foo.txt in rev 100, delete it in rev 110 and then create a brand new, unrelated (as far as history is concerned) foo.txt and add it in rev 115, then svn log foo.txt only shows -r 115:HEAD by default. I will not see anything from -r 100:110

To clarify, even specifying -r 0:HEAD to svn log will still only show changes in -r 115:HEAD. In the example I just gave, even if I specify a peg revision (foo.txt@100) it still doesn't show the delete in rev 110, and svn log foo.txt@110 complains that the file doesn't exist in rev 110. So, the only way I can see to see ALL of the history associated with the path is to get the log for the directory. Of course, if the directory also has disjoint history segments, you have to move up to ITS directory, potentially until one reaches the root. *sigh*

So then I think my answer of “no” is correct. In the future, you can prevent gaps in the history by restoring a deleted file from an old revision rather than creating a new one at the same path. In this way, SVN’s history will track it in the way you want. Only if the files are truly unrelated should you create a new one, and in this case you wouldn’t want the history to track the old file.

Actually, I think the answer of "no" is incorrect. In several cases, I actually do want the files to be unrelated, e.g. the old file was later refactored to a few other files, and, since it wasn't well named to begin with, we created a new file with the same name that actually serves the purpose of the original. However, for reporting, we still need to know available peg revisions for a given path. I still don't see a mechanism that is correct for all possible situations besides a walk of the entire path status history for the entire repository.