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. -- WBR, Andrey Repin (anrdae...@freemail.ru) 28.11.2010, <9:13> Sorry for my terrible english...
