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
Regards,
Daniel B.
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2425789
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2009-12-01 10:41:31 CET