On Sun, Nov 28, 2010 at 7:28 AM, Andrey Repin <anrdaemon_at_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/test@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/test@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
Received on 2010-11-28 10:06:12 CET