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 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.
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)
>
> >
> >>> 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).
Regards,
David
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=1277821
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2009-03-06 16:38:58 CET