> Open issue here: Imagine two users A and B. File X in the repo is newer
> than their working copies.
>
> A runs synchronize
> B runs synchronize
> A commits file X
> B updates file X
>
> What will B expect to get?
It depends. If B knows about A's change they probably would have expected
to get it. If they are relying on what Subclipse is showing them, then
they would probably expect to get the revision they see.
> A runs synchronize
> B runs synchronize
> A commits file X
> B updates file X
> B changes file X
> B commits file X
> A updates dir of file X
>
> (note: both users run sync just *once*).
>
> Will A expect the file to change?
In the current software, B would not be able to commit because when they
did their update they did not receive A's change and would be out of date.
As for your question, if you do an update on a dir you have to be assuming
that you are doing it with the expectation of getting any changes within
that directory.
> Maybe the only solution is to go back to individual updates but to group
> them by revision numbers:
That isn't necessary. If file A is at revision 100, and B is at revision
90, then updating them both to revision 100 is the safe thing to do. The
way they view works, B could not have been changed between 90 and 100.
> Another solution: During sync, request an actual update but don't apply
> it, yet. Apply the parts of the update individually when the user
> requests it.
Not even remotely possible,
Mark
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. and SoftLanding Europe Plc by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subclipse.tigris.org
For additional commands, e-mail: users-help@subclipse.tigris.org
Received on Sun Feb 26 14:49:08 2006