[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: display problem with TortoiseMerge

From: Simon Large <simon.tortoisesvn_at_gmail.com>
Date: Thu, 29 Nov 2012 09:09:05 +0000

On 29 November 2012 09:08, Stefan Wild <stefan.wild_at_afr-consulting.de> wrote:
> Am 03.08.2012 07:41, schrieb Stefan Wild:
>> Am 26.06.2012 09:07, schrieb Stefan Wild:
>>> Am 25.06.2012 21:41, schrieb Stefan Küng:
>>>> On 22.06.2012 13:39, Stefan Wild wrote:
>>>>>> Changed this so that the three files compared are:
>>>>>> BASE : the file before the update
>>>>>> THEIRS: the file in HEAD
>>>>>> MINE : the local file, probably with local modifications
>>>>>>
>>>>>> You can try a nightly build >= r23020
>>>>>>
>>>>>> Stefan
>>>>>>
>>>>>
>>>>> thanks! I tried it, merge (green) now looks fine, but updated files
>>>>> still compare with last revision, not my wc. (I see the changes I
>>>>> just got AND the last changes I committed)
>>>>
>>>> Have a look at the picture in the docs here:
>>>> http://tortoisesvn.net/docs/release/TortoiseMerge_en/tmerge-basics-conflicts.html
>>>>
>>>> What you see in the left and right view are the diffs between "theirs"
>>>> and "base" (left) and "yours" and "base" (right).
>>>>
>>>> The view at the bottom shows then the result, i.e. your local file "yours".
>>>>
>>>> What files would you use to show here instead?
>>>>
>>>> Stefan
>>>
>>> hm, I think that's right, conflicts (red) and merged files (green) seem to be ok
>>> but when I get an updated file (black), what are the files then?
>>> Base: my file before the update, e.g. rev.7900
>>> Theirs: HEAD, e.g. rev.7901
>>> Yours (Mine): is also my file before the update, e.g. rev.7900
>>> "Merged": though no merge was necessary, it's HEAD, e.g. rev.7901
>>>
>>> But it looks like it's comparing with rev.7899 (or less) in this example, a revision before I committed 7900.
>>> That's what I mean, I can see the new changes and the old changes.
>>> I used to look through the updated files to see what my coworkers committed (to either compliment or criticise them)
>>> But curiously I see my last committed changes too.
>>> I'm not good @ explaining, I know ^^
>>
>> I got that problem again with updated (black) files. Now it's really clear.
>> I commited rev.8043 and added a new file. My coworker modified this and other files and committed rev.8046 and then 8047. Now I update my WC with rev.8048 (44, 45, 48 were changes to other files) and get "Updated (this file)" in black letters. But when I try to "compare with working copy" it doesn't show the changes I got in this moment (8043->8047), but tries to compare with revision 8042, where this file didn't yet exist.
>> Error message is:
>>
>> [Window Title]
>> TortoiseSVN
>>
>> [Main Instruction]
>> Subversion reported an error:
>>
>> [Content]
>> Unable to find repository location for
>> 'M:\mypath\myfile.pm' in
>> revision 8042
>>
>> [Schließen]
>
> Hi,
> this problem still exists. The nightly build I tried back then seems not to be implemented in the latest release.
> Yet I see changes from long before instead of (or additional to) recent changes.
> As written above (03.08.2012), "compare with working copy" or similar processes compare with too old revisions. So these functions are rather useless at the momenent...
> Do you need more information?

The 1.7.x releases are all taken from the 1.7.x stable branch. That
change was on trunk so you won't see it until 1.8.0 is released.

Simon

--
:       ___
:  oo  // \\      "De Chelonian Mobile"
: (_,\/ \_/ \     TortoiseSVN
:   \ \_/_\_/>    The coolest Interface to (Sub)Version Control
:   /_/   \_\     http://tortoisesvn.net
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=3031978
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2012-11-29 10:09:11 CET

This is an archived mail posted to the TortoiseSVN Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.