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...
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.
> 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.
>> 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.
Again, this is my understanding of how things should work.
--
Regards,
Jean-Marc
--
. ___
. @@ // \\ "De Chelonian Mobile"
. (_,\/ \_/ \ TortoiseSVN
. \ \_/_\_/> The coolest Interface to (Sub)Version Control
. /_/ \_\ http://tortoisesvn.net
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2425783
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2009-12-01 10:24:51 CET