On 11/27/10 9:06 PM, Andrey Repin wrote:
>
>> 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 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 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. The log
of the renamed file will have it, as will the directories containing the changes
to the names.
>> 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.
> [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 guess it could be more polite about giving you
the revisions it can find along with the error.
>> 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.
The tags should be irrelevant since nothing should change there unless you want
to use one as source for a copy back to a branch for changes. If you know the
file in question existed in a tag, you can track backwards from there though,
or copy into a current revision.
> 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.
I'd probably feed the output to an editor or 'less', search for the delete of
the path than back up to the revision. There are probably fancier things you
could do with the xml output.
--
Les Mikesell
lesmikesell_at_gmail.com
Received on 2010-11-28 05:42:50 CET