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

Re: After update file still on list

From: Stefan Küng <tortoisesvn_at_gmail.com>
Date: Fri, 06 Mar 2009 16:41:19 +0100

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:
>>>>>>>>>>> Stefan Küng wrote:
>>>>>>>>>>>> David Balažic wrote:
>>>>>>>>>>>>> TortoiseSVN 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.
> Yes. There is a conflict. Not a "conflict-after-update".
> I did not involve any update.
> I just edited a file (which was not in conflict at that time).
> The I called CfM, and it shows modified/modified.
> I did not do any update. (except a day before, of course; but from
> your wording, I understood that the act of updating would somehow
> create a conflict)

Then the file is *not* in conflict. If you simply modified the file and
you didn't do an update, you don't have 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).
> Yes. That is one thing: how is it currently implemented.
> And there is another thing: you claim the window can not be updated.
> That are two different things. I perfectly understand the first one.
> The second is moot. You claim the CfM window can not be automatically
> updated to latest state regarding files that have been just updated.
> I say they can (off course with code changes).

Sure, we could send a message from the updating process back to the CfM
dialog telling it to refresh. But that would interrupt the user with
whatever he's doing right now with the CfM dialog.
Pressing F5 is much better: the user can choose himself *when* to refresh.


  oo  // \\      "De Chelonian Mobile"
 (_,\/ \_/ \     TortoiseSVN
   \ \_/_\_/>    The coolest Interface to (Sub)Version Control
   /_/   \_\     http://tortoisesvn.net
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].

Received on 2009-03-06 16:41:48 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.