Re: After update file still on list

David Balažic wrote:
> Stefan Küng wrote:
>
>> David Balažic wrote:
>>> Stefan Küng wrote:
>>>
>>>> David Balažic wrote:
>>>>> Stefan Küng wrote:
>>>>>
>>>>>> David Balažic wrote:
>>>>>>> Stefan Küng wrote:
>>>>>>>
>>>>>>>> David Balažic wrote:
>>>>>>>>> Stefan Küng wrote:
>>>>>>>>>
>>>>>>>>>> David Balažic wrote:
>>>>>>>>>>> TortoiseSVN 1.5.9.15518 32-bit
>>>>>>>>>>>
>>>>>>>>>>> In the "check for Modifications" windows, an remotely
>>>>>>>> modified file
>>>>>>>>>>> does not disappear from the list, after calling
>> Update on it.
>>>>>>>>>> Hit F5 to refresh the view.
>>>>>>>>> No, that removes all remote changes. Then I have to click
>>>>>>>> again "Check repository" to get them back.
>>>>>>>>> I also noticed now, that localy changed files also do not
>>>>>>>> disappear from the list after bein commited.
>>>>>>>>> I vaguelly remember that they did so in previous versions...
>>>>>>>> Nope, that never worked that way.
>>>>>>>>
>>>>>>>> Because: how would the CfM dialog even know that an
>>>>>>>> update/commit/whatever was successful? That is done in a
>>>>>>>> separate thread.
>>>>>>> And communication between threads will be invented only
>>>>>> next year ;-)
>>>>>>> I know this is not 5 minutes of work... I program myself.
>>>>>> After you update a folder or a file, what status does it have
>>>>>> (assuming the update was successful)?
>>>>> "up-to-date" (that is : no remote changes)
>>>> Nope. Well, the *remote* status would be 'normal', yes.
>> But what would
>>>> the local text and property status be? Could be 'normal', could be
>>>> 'conflicted', could be 'modified', could be ...
>>> Yes. If the user would modify it the same time he is updating it.
>>> Which is done very rarely.
>> Instead of trying to prove my arguments wrong, please do all of us a
>> favor and *think* first about what I wrote.
>> Your argument is completely wrong, and if you ever had a
>> conflict after
>> an update you would know it (and from your other mails I get that you
>> already *have* had a conflict after an update).
>
> The todays mail ? It is not a conflict after update.

But it is a conflict, then how did you get such a conflict?
You said:

"I have to gou to explorer, browse down to the file in question,
right click it, select "Edit conflicts", which brings up the same window
as before, but now the "Mark as resolved" button is enabled."

So if you get the "Edit conflicts" menu from explorer, there is a conflict.

>
>>> Afterall why are reverted files removed from the list ?
>> Didn't I just tell you that in my very first answer? If you can't
>> remember what I wrote half an hour ago, then at least re-read
>> the mails
>> again.
>>
>>> The code is following two logics here, without any
>> explanation, why is one good
>>> in one case, and the other in other case.
>> I gave you an explanation why.
>
> Yes. You said it is one thread vs two threads.
>
> Which does not answer the core question:
> - why is once the status updated (even if it could be wrong) and once not

I said: "That's done in the CfM dialog itself and therefore the CfM
dialog knows about success/failure of that command. So it can update (or
not)."

And I also said that the other commands are not done in the CfM dialog
itself but in another separate dialog (even in a separate process, not
thread).

Stefan

-- 
       ___
  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=1277739
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].