Ben Collins-Sussman <sussman@red-bean.com> wrote on 10/14/2004 09:28:04
AM:
> Suppose a user 'hijacks' revision 4 of a file, edits it. Meanwhile
> somebody else locks r4, commits r5, then releases the lock.
>
> The hijacking user fails to commit, then fails to lock, so eventually
> runs 'svn up' as instructed. Their 'text-base' is updated to r5 (and a
> copy of r5 is placed into a backup file) but the working file doesn't
> absorb any r5 changes. It continues to be a modified version of r4.
> When the user locks, the lock succeeds, because the working copy *does*
> have r5 now: both the working-rev and text-base are r5. When the user
> commits, they end up removing all of the r5 changes and adding their
> own r4-based changes.
>
> This is how conflicts already work right now. What's being left out is
> the marking of the file as conflicted, the 3 text bases, and the need
> to run 'svn resolved'.
The part I disagree with is not marking it conflicted and requiring svn
resolve. I do not care how difficult that may be for a user to
understand. You cannot let someone create a conflict and not tell anyone.
That is not helping at all.
Mark
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Oct 14 15:32:13 2004