On Wed, Dec 2, 2009 at 4:40 AM, Stefan Küng <tortoisesvn_at_gmail.com> wrote:
> On 01.12.2009 08:33, Daniel Becroft wrote:
>> On Tue, Dec 1, 2009 at 5:19 PM, Jean-Marc van Leerdam
>> <j.m.van.leerdam_at_gmail.com> wrote:
>>> Daniel,
>>>
>>> First off, I am not a very experienced SVN user, so my analysis may be
>>> off a bit. But I am sure my fellow readers will jump in to correct me
>>> if I'm wrong...
>>
>> No problem, neither am I. That's why I'm asking the question.
>>
>>> 2009/12/1 Daniel Becroft<djcbecroft_at_gmail.com>:
>>>> On Tue, Dec 1, 2009 at 4:16 PM, Jean-Marc van Leerdam
>>>> <j.m.van.leerdam_at_gmail.com> wrote:
>>>>> I think it has to do with the logic that determines 'this path'. AFAIK
>>>>> the logic operates like this:
>>>>> For a single file request, the history of that particular file is seen
>>>>> as the context in which the request is made, hence it's content at the
>>>>> original location is taken to compare with.
>>>>
>>>> But even that is not what is happening. Given the following revision
>>>> (r25) that adds the following file:
>>>>
>>>> + alpha/beta/source-modified/foo.c (copied from
>>>> /alpha/beta/source-base/foo.c @ r10)
>>>>
>>>> If I view the log for the /alpha path, select r25, and "Compare with
>>>> Previous Revision", then I get a list of all the changed files between
>>>> o/alpha_at_10, and /alpha_at_25, which includes changes t /alpha/gamma,
>>>> /alpha/readme.txt, etc. None of which have been modified in the
>>>> selected revision.
>>>>
>>>
>>> Yes, because a file that gets replaced with a copy of another file is
>>> called a changed file, even if the contents are the same. For
>>> subversion it is a replacement with something unrelated, hence a
>>> change.
>>
>> Agreed.
>>
>>>> Interestingly, even if I view the log for the
>>>> /alpha/beta/source-modified path, select r25, and "Compare with
>>>> Previous Revision", I still get a list of all the changes between
>>>> /alpha/beta/source-modified_at_10, and /alpha/beta/source-modified_at_r25.
>>>>
>>>> If it is tracing back the file to find the individual file's previous
>>>> revision, then that's fine, but why then does it apply that revision
>>>> to the parent path?
>>>>
>>>
>>> I am not sure what you describe here, it could be that multiple copies
>>> from source-base to source-modified (and back?) play into this.
>>
>> Possibly - but these are all one-way copies (source-base to
>> source-modified), never back the other way.
>>
>>>>> For a request with multiple files, the common path ancestor of these
>>>>> files is used, and files are matched against files from the same
>>>>> ancestor tree as it was in the revision. Files are then compared if
>>>>> they have the same name (even if their history is completely
>>>>> unrelated).
>>>>
>>>> Still not sure I understand this.
>>>>
>>>
>>> What I tried to explain is that if you ask for a 'compare with
>>> previous revision' on multiple files, SVN will find the common path
>>> ancestor and use that to compare two trees of files. Example: HEAD is
>>> r30, you ask for a compare with previous revision on two files
>>> /a/b/ccc/foo.bar and /a/b/ddd/bar.bar. SVN determines the common
>>> ancestor path is /a/b and will then provide a list of changes between
>>> /a/b_at_r29 and /a/b_at_r30.
>>
>> Even this isn't consistent with what it is doing. It is applying the
>> @r29 and @r30 against whatever path I have initiated the Log Messages
>> dialog for, not the common ancestor.
>>
>> E.g. If I "View Log" for /alpha, then I get /alpha_at_r29 and /alpha_at_r30.
>> /alpha/beta> /alpha/beta_at_r29 and /alpha/beta_at_r30, etc.
>>
>> I'm not even sure of the equivalent 'svn' commands that correspond
>> with the TSVN "Compare with Previous Revision" command. I'm expecting
>> to get the equivalent of:
>>
>> svn diff --summarise -c 25 svn://.../alpha
>>
>> but instead it's giving me
>>
>> svn diff --summarise -r 10:25 svn://.../alpha
>
> sorry for the late reply. Had to ship heavy snow for an hour yesterday
> after work and then just didn't have the energy to work on TSVN anymore...
>
> You're right, the diff should only use the copyfrom revision if the
> relative url matches the one you show the log for.
> This is a bug, but it only happens if there's only one move/rename done
> in a revision with no other changes (i.e., only two lines shown in the
> bottom pane of the log dialog).
>
> Fixed in r17771.
>
> Stefan
Thanks, Stefan. I'm just pleased I wasn't going totally nuts and
completely misunderstanding the issue.
I'll wait for the next nightly build and give it a quick test.
Cheers,
Daniel B.
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2426146
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2009-12-02 00:46:03 CET