How to read 3-way differences in TortoiseMerge?
Robert Dailey
When I do an SVN Update, I notice a few items that are "Merged" (green). I right click these and go to "Compare with Working Copy" because I'm interested in seeing *what was merged into what I already have*. However, I end up getting horribly confused because it's not showing me anything useful. I have no idea how to read the differences. What is it comparing against?
Stefan Küng
It shows you on the top left the file from the repository, compared
against BASE. On the right, you see your file (with your local
modifications) compared against BASE.
And on the bottom, you see the merged result, compared against BASE.
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
Robert Dailey
Robert Dailey wrote:It shows you on the top left the file from the repository, compared against BASE. On the right, you see your file (with your local modifications) compared against BASE.
Hi,
When I do an SVN Update, I notice a few items that are "Merged" (green). I right click these and go to "Compare with Working Copy" because I'm interested in seeing *what was merged into what I already have*. However, I end up getting horribly confused because it's not showing me anything useful. I have no idea how to read the differences. What is it comparing against?
And on the bottom, you see the merged result, compared against BASE.
Simon Large
> Robert Dailey wrote:
>>
>> On Wed, Jul 23, 2008 at 11:38 AM, Stefan Küng <torto...@gmail.com
>> <mailto:torto...@gmail.com>> wrote:
>>
>> Robert Dailey wrote:
>>
>> Hi,
>>
>> When I do an SVN Update, I notice a few items that are "Merged"
>> (green). I right click these and go to "Compare with Working
>> Copy" because I'm interested in seeing *what was merged into
>> what I already have*. However, I end up getting horribly
>> confused because it's not showing me anything useful. I have no
>> idea how to read the differences. What is it comparing against?
>>
>>
>> It shows you on the top left the file from the repository, compared
>> against BASE. On the right, you see your file (with your local
>> modifications) compared against BASE.
>> And on the bottom, you see the merged result, compared against BASE.
>>
>>
>> What version from the repository is being compared against base in the
>> top-left window? I noticed changes in there that were from a few revisions
>> back from what I actually got during this particular update. What two files
>> are being merged in the bottom pane?
>
> The revision from the repository is the last-commit-rev of the item you've
> updated (usually the parent folder).
>
> the bottom pane shows the merge result of the file in the repository and
> BASE.
I sometimes wondered why the diff there shows many more changes than I
was expecting. What I would hope to see is the 3-way diff between BASE
as it was before the merge, my local changes and BASE as it is now
after the update. I guess the information about the previous BASE is
lost as part of the update :-(
Since the parent folder will change its commit rev very infrequently
(prop changes?) then the 3-way diff seems practically useless.
Simon
--
: ___
: oo // \\ "De Chelonian Mobile"
: (_,\/ \_/ \ TortoiseSVN
: \ \_/_\_/> The coolest Interface to (Sub)Version Control
: /_/ \_\ http://tortoisesvn.net
---------------------------------------------------------------------
To unsubscribe, e-mail: users-un...@tortoisesvn.tigris.org
For additional commands, e-mail: users...@tortoisesvn.tigris.org
Robert Dailey
Robert Dailey wrote:The revision from the repository is the last-commit-rev of the item you've updated (usually the parent folder).
On Wed, Jul 23, 2008 at 11:38 AM, Stefan Küng <torto...@gmail.com <mailto:torto...@gmail.com>> wrote:
Robert Dailey wrote:
Hi,
When I do an SVN Update, I notice a few items that are "Merged"
(green). I right click these and go to "Compare with Working
Copy" because I'm interested in seeing *what was merged into
what I already have*. However, I end up getting horribly
confused because it's not showing me anything useful. I have no
idea how to read the differences. What is it comparing against?
It shows you on the top left the file from the repository, compared
against BASE. On the right, you see your file (with your local
modifications) compared against BASE.
And on the bottom, you see the merged result, compared against BASE.
What version from the repository is being compared against base in the top-left window? I noticed changes in there that were from a few revisions back from what I actually got during this particular update. What two files are being merged in the bottom pane?
the bottom pane shows the merge result of the file in the repository and BASE.
You say it's the merge result of the last commit revision and BASE. BASE I'm assuming is the lastest revision of that file that I have in my working copy. The last commit revision seems like it would be the exact same thing, since my last update OBTAINED the last commit revision (as it would have been committed by someone else). The file showed the following:
- The changes for *this* update (the update that resulted in me viewing the diff in the first place)
- Changes from about 2-3 updates back (These shouldn't be showing up, as they have nothing to do with what I care about... which is the changes obtained in *this* update)
Simon Large
I'm guessing here, but I could imagine TSVN noting the last-commit
revision of the item being updated before doing the update, then using
that revision as the basis for the 3-way diff. Does that make any more
sense of your data?
Simon
--
: ___
: oo // \\ "De Chelonian Mobile"
: (_,\/ \_/ \ TortoiseSVN
: \ \_/_\_/> The coolest Interface to (Sub)Version Control
: /_/ \_\ http://tortoisesvn.net
---------------------------------------------------------------------
Robert Dailey
2008/7/23 Robert Dailey <rcda...@gmail.com>:
I'm guessing here, but I could imagine TSVN noting the last-commit>
> I'm still pretty confused about that top-left pane.
>
> You say it's the merge result of the last commit revision and BASE. BASE I'm
> assuming is the lastest revision of that file that I have in my working
> copy. The last commit revision seems like it would be the exact same thing,
> since my last update OBTAINED the last commit revision (as it would have
> been committed by someone else). The file showed the following:
>
> The changes for *this* update (the update that resulted in me viewing the
> diff in the first place)
> Changes from about 2-3 updates back (These shouldn't be showing up, as they
> have nothing to do with what I care about... which is the changes obtained
> in *this* update)
>
> Sorry for being slow about this. I appreciate you taking the time to explain
> this to me.
revision of the item being updated before doing the update, then using
that revision as the basis for the 3-way diff. Does that make any more
sense of your data?
Say we have a file named foo.cpp that has 3 commit revisions (In other words, I committed the file 3 times and each commit resulted in the corresponding revision number): 10 29 48
When I do an update that gives me foo.cpp at revision 48, are you saying that it will diff the changes between 29 and 48 in the top-left pane? If this is so, why am I seeing changes that should only be showing up when I diff between 10 & 29?
Robert Dailey
Stefan Küng
> Say we have a file named foo.cpp that has 3 commit revisions (In other
> words, I committed the file 3 times and each commit resulted in the
> corresponding revision number): 10 29 48
>
> When I do an update that gives me foo.cpp at revision 48, are you saying
> that it will diff the changes between 29 and 48 in the top-left pane? If
> this is so, why am I seeing changes that should only be showing up when
> I diff between 10 & 29?
No, it will show you (most likely) the diff between 10 & 48. Because it
will use the revision of the directory before the update, and that's
most likely your revision 10 if you haven't updated in between.
This feature of course only works 'good' if you update your working copy
often.
Stefan
Robert Dailey
Robert Dailey wrote:No, it will show you (most likely) the diff between 10 & 48. Because it will use the revision of the directory before the update, and that's most likely your revision 10 if you haven't updated in between.
Say we have a file named foo.cpp that has 3 commit revisions (In other words, I committed the file 3 times and each commit resulted in the corresponding revision number): 10 29 48
When I do an update that gives me foo.cpp at revision 48, are you saying that it will diff the changes between 29 and 48 in the top-left pane? If this is so, why am I seeing changes that should only be showing up when I diff between 10 & 29?
This feature of course only works 'good' if you update your working copy often.
Perhaps my expectations are incorrect? What was the reason behind how it behaves now? What is it meant to satisfy?
Stefan Küng
> No, it will show you (most likely) the diff between 10 & 48. Because
> it will use the revision of the directory before the update, and
> that's most likely your revision 10 if you haven't updated in between.
> This feature of course only works 'good' if you update your working
> copy often.
>
>
> Help me understand exactly how this is useful. First of all, when I see
> something has "Merged" during an update, when I Diff that I would expect
> to see the difference between the latest version of that file and the
> revision right before it (So I can see exactly what was changed).
You will see that, but only if you did an update after you've last
committed the now merged file.
> However, if the Merge happens and it includes several revisions, I would
> expect to see a difference then between the last updated version I had
> and the head revision. Note in all of this I do not care about seeing my
> own local working copy changes in the Diff.
The same here: if you have updated after you last committed that file,
you will get the merge view with the correct revisions.
> Perhaps my expectations are incorrect? What was the reason behind how it
> behaves now? What is it meant to satisfy?
TSVN does not know which files are affected in an update *before* the
actual update. But after the update has finished, it can't check what
revision the file was at in the working copy before the update to show
you the diff you would expect.
So the only workaround is to get the revision the folder you run the
update on has in the working copy before the update.
Robert Dailey
You will see that, but only if you did an update after you've last committed the now merged file.
Not sure what you mean here. If my working copy has revision 2 of a file committed by user "foo" and I'm doing an update that gets revision 3 committed by user "bar", it should show the changes between revision 2 and 3, yet it is showing changes between 1 and 3. Why do I have to commit the file being merged in order for this to work right? I can't do that anyway, because I have to update (to get the latest version) before I'm allowed to commit that file. Could you please clarify with examples?
TSVN does not know which files are affected in an update *before* the actual update. But after the update has finished, it can't check what revision the file was at in the working copy before the update to show you the diff you would expect.
So the only workaround is to get the revision the folder you run the update on has in the working copy before the update.
Here is what I would expect TortoiseSVN to do without having looked at the implementation:
- User performs an "Update" on a specific directory in a working copy
- During the update process, temporarily store the revision number of the current working version for each file that is updated.
- When the update is complete, it now has a list of old revisions before the update for only those files updated.
- When the user does a "Diff" on merged items, it will show the diff between that temporarily stored revision number and the new updated revision
Stefan Küng
> On Mon, Jul 28, 2008 at 9:55 AM, Stefan Küng <torto...@gmail.com
> <mailto:torto...@gmail.com>> wrote:
>
> You will see that, but only if you did an update after you've last
> committed the now merged file.
>
>
> Not sure what you mean here. If my working copy has revision 2 of a file
> committed by user "foo" and I'm doing an update that gets revision 3
> committed by user "bar", it should show the changes between revision 2
> and 3, yet it is showing changes between 1 and 3. Why do I have to
> commit the file being merged in order for this to work right? I can't do
> that anyway, because I have to update (to get the latest version) before
> I'm allowed to commit that file. Could you please clarify with examples?
Layout:
wc
wc\file
* update wc. wc at rev2
* modify file, commit -> file at rev3
* modify file, commit -> file at rev4
* modify file, commit -> file at rev5
* someone else modifies file and commits, repo at rev6
* update, file gets merged
* diff shows r2 of file as "theirs", r6 of file as "base" and WC as "mine"
But, the same sequence a little different:
* update wc. wc at rev2
* modify file, commit -> file at rev3
* modify file, commit -> file at rev4
* modify file, commit -> file at rev5
* update wc. wc is at rev5
* someone else modifies file and commits, repo at rev6
* update, file gets merged
* diff shows r5 of file as "theirs", r6 of file as "base" and WC as "mine"
> Here is what I would expect TortoiseSVN to do without having looked at
> the implementation:
>
> 1. User performs an "Update" on a specific directory in a working copy
> 2. During the update process, temporarily store the revision number
> of the current working version for each file that is updated.
Here's the problem: that's not possible. The svn library notifies the
client *after* it has already updated the file. There's no way to find
the revision of the file before an update (unless we would first scan
the whole working copy to get the revs of *every* file).