Simon Large wrote:
> 2009/3/19 Stefan Küng <tortoisesvn_at_gmail.com>:
>> Simon Large wrote:
>>> 2009/3/19 Stefan Küng <tortoisesvn_at_gmail.com>:
>>>> Simon Large wrote:
>>>>> Hi folks,
>>>>>
>>>>> I made a mistake when trying to merge earlier this evening. I merged
>>>>> trunk/doc into branches/1.6.x/doc/source and got a tree conflict on
>>>>> source. Oops, revert that!
>>>>>
>>>>> Now I have a conflicted overlay on source, but CfM shows no conflicts,
>>>>> and I am allowed to commit from the top level doc folder. Since then I
>>>>> upgraded to the latest nightly, and also tried cleanup, but nothing
>>>>> will clear the conflicted overlay. Killing TSVNcache.exe clears it for
>>>>> a short time, but after a while it goes back to conflicted. svn status
>>>>> shows no conflicts either.
>>>> Can't reproduce this.
>>>> * show log for 'doc'
>>>> * select r15754, right-click, "merge revision to...", select
>>>> 1.6.x\doc\source as the target
>>>> * tree conflict on 1.6.x\doc\source
>>>> * revert
>>>>
>>>> the overlay changes back to 'normal' as it should.
>>>> And it stays as 'normal' even after waiting 10 minutes and two
>>>> 'cleanup's on 1.6.x.
>>>>
>>>> I used r15754, assuming that's the merge you attempted?
>>>> Maybe you merged a different way or another revision?
>>> Not sure exactly how to reproduce it, but this is a cut down version
>>> of the working copy with most of the content excluded. It still shows
>>> clean in CfM and has a conflicted overlay.
>> Now that's *very* strange!
>> If you check the "Show ignored files" in the CfM dialog for that working
>> copy, the tree conflicts show up. Even though they're not ignored, a
>> normal 'svn st' treats them as such and won't show them.
>>
>> This really looks like a bug in the svn library.
>> But since this only happens with a bogus merge (at least for now?), I
>> think this is not a showstopper for the 1.6 release.
>
> I guess CfM gets all statuses anyway, so can it make conflicted items
> show up anyway, even if ignored?
Not really: if the checkbox is not activated, then the --no-ignore flag
is not passed to the svn_client_status() API. The --no-ignore flag can
cause a *lot* more disk access, that's why we don't pass it if not
explicitely requested. The status cache however has to pass that flag to
get info about all files/folders because explorer asks for all too.
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=757&dsMessageId=1358054
To unsubscribe from this discussion, e-mail: [dev-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2009-03-19 22:23:23 CET