Greetings, Les Mikesell! >>> The deletion should show in an 'svn log -v' of the directory where the file >>> was >>> deleted. >> >> That directory was deleted as well. As well, at unknown revision. Multiple >> times. >> >> The question is not that we can work around the issue, the question is, why >> Subversion can't do this for us?
> Because the file doesn't exist in the revision where it was deleted so > there's > nothing for the log to be about. That's a flaw, but well, I can live with it as long as there's other ways to get necessary info. > The change for that rev happened in the directory above. I'm looking for directory already, as file history would not show me the necessary data. Dunno why... is it hard to track file from PEG revision to first operative revision and print out the logs for every revision, in which that file were changed, and spit the "not found in rev X" when the file disappear? Why it even think that file could exist in HEAD, when we unambiguously pointed to the specific point in time? >> I can understand that it's not easy to track deletes/copies forward, but >> tracking history from creation time to deletion(renamind implies >> deletion) time should be possible IMO. > It is not that it isn't tracked. It just isn't tracked where you are looking > for it. I'm looking for it at revision 2. [C:\]$svn log -v -r 0:HEAD -- http://svn.darkdragon/repos/t...@2 svn: '/repos/!svn/bc/35/test' path not found [C:\]$svn log -v -r 0:3 -- http://svn.darkdragon/repos/t...@2 ------------------------------------------------------------------------ r1 | anrdaemon | 2009-04-02 17:55:17 +0400 (×ò, 02 àïð 2009) | 2 lines Changed paths: A /test A /test/a Test1 ------------------------------------------------------------------------ r2 | anrdaemon | 2009-04-02 17:56:13 +0400 (×ò, 02 àïð 2009) | 1 line Changed paths: A /test/b test 2 ------------------------------------------------------------------------ r3 | anrdaemon | 2009-04-02 17:56:48 +0400 (×ò, 02 àïð 2009) | 1 line Changed paths: R /test/a Test 3 ------------------------------------------------------------------------ >> And this should be possible without user's guesswork. It's fairly simple to >> find correct revision range in repository with 40 commits. >> In repository with 40,000 commits things became "a bit" scary. > Subversion tracks things backwards from a starting point that is either > something that exists or a peg revision where it did exist. I know. Quite. And if you didn't noticed, I specifically specified (LOL) a PEG revision... With exactly that intent - to get around absence of file in HEAD... > You can find where things were deleted with a 'log -v' of a directory high > enough in the repository to contain the change, then use the previous > revision as the peg rev for the thing you want to log from there back while > it existed. Project contains 40,000 revisions, about 800 files, like eight branches, that was created/deleted/recreated at some point each, and approximately 25 tags denoting "stable" builds. Good luck finding directory LOW enough that allow you to find a file without use of a sophisticated log parser, since revision numbers are not connected to changed files in any way suitable for meaningful grep'ing. -- WBR, Andrey Repin (anrdae...@freemail.ru) 28.11.2010, <5:50> Sorry for my terrible english...
