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

Re: Locking consensus(es) so far

From: Mark Phippard <MarkP_at_softlanding.com>
Date: 2004-10-14 15:31:28 CEST

Ben Collins-Sussman <sussman@red-bean.com> wrote on 10/14/2004 09:28:04

> 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.


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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.