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:
>>> 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
>>>> 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
>>>> 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.
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.
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2009-12-02 00:46:03 CET