On Sun, Nov 28, 2010 at 7:28 AM, Andrey Repin <anrdae...@freemail.ru> wrote: > Greetings, Les Mikesell! > >>>> 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? > >> It doesn't track the future of a file, it tracks the history. Start with a >> peg >> revision > > Wat? It start with HEAD irrelevant to what PEG revision we've specified. > And immediately spitting "no such file", although the file is 100% there. > >> of the revision before the delete and the log will track it back >> through it's entire history. > >>> Why it even think that file could exist in HEAD, when we >>> unambiguously pointed to the specific point in time? > >> It won't look towards HEAD unless you request that in the revision range for >> the >> log, and then it will be impossible. > > I specified PEG revision. Documentation clearly states that PEG revision has > precedence over operative revision in conflicting names resolution, but for > absent files (name conflicting with void) it not seems to be the case. > >>>>> 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. > >> Actually, while renaming implies deletion, it is not a loss of history. > > Yes, but it's still a deletion. > >> The log of the renamed file will have it, as will the directories containing >> the changes to the names. > > Unfortunatelly. It only show that file was renamed, but does not show the new > name. (Or old name? One of them - see the log below) > >>>> 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 > >> But you are asking it to track the future of that file to a place it doesn't >> exist. > > I beg to differ. > I'm asking to > 1. Pick the file (directory) /test at revision 2 > 2. Track it's changes history from revision 0 to HEAD. > 3. I'm fully aware that the directory does not exist in HEAD, neither I ask > Subversion to look there in first place. (literal meaning of "first place") > 4. Quite (un)surprisingly, my intent is to actually find revision, in which > the destruction was made. Because, quite (un)surprisingly, I don't know that. > > See the order of instructions? Do I need to refer to the svnbook chapter > discussing PEG and operative revisions, or you can find it yourself? > >>> [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... > >> But you can only expect it to track the history and it appeared that you >> wanted >> to track the future to HEAD. > > I could have pointed to any other of the revisions between @PEG and HEAD, > which will net the very same result - unless I guess it right, the process > will not start at all. > >> I guess it could be more polite about giving you the revisions it can find >> along with the error. > > Nah, it could just obey to @PEG rule. Everything will be simpler. > Unless there's absolutely no other way to track the file from @PEG, which i > doubt, since you DO can access the file by @PEG, as well as navigate back in > time easier, than forward.
FWIW, you do have a point, Andrey (and others), that this is a valid use case (finding the rev in which a file was deleted) which isn't well supported by svn currently. I think the svn devs are very much aware of this, but it just isn't there yet. See also this issue: http://subversion.tigris.org/issues/show_bug.cgi?id=3627 - FS API support for oldest-to-youngest history traversal It literally mentions this use case as one of the "high-level user needs": " - allowing 'svn log' to fully traverse the entire history of a given versioned object, both for completeness' sake and to facilitate (for example) resurrection of deleted items from their most-recently-existing forms." Unfortunately, according to the current plans, it might be a while before this is implemented. On the roadmap, it is listed as being dependent on FS-NG ("Flexible Repository Storage"), on the list of "most wanted features": http://subversion.apache.org/roadmap.html#features-most-wanted. In the meantime: thanks to other users for suggesting techniques to handle this. Cheers, -- Johan