[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: Ben Collins-Sussman <sussman_at_red-bean.com>
Date: 2004-10-13 23:16:45 CEST

On Oct 13, 2004, at 5:06 PM, Mark Phippard wrote:

>> The goal here is that the "non VC" user never ever sees a Conflict.
>> We
>> don't want non-techies to see a "C" next to a file, to have to
>> understand the 3 fulltexts, or the 'svn resolved' command. Go look at
>> the 'hijack' section of the UI document to understand this motivation.
> I understood the motivation, I just didn't understand how the proposal
> solved it. Also, what I am mainly interested in is that if someone
> uses
> this feature with say a .c file, that I think it ought to work the way
> it
> currently does. If the file is not mergeable, then I have no
> objection to
> making it work differently. Although, personally, I think it should
> raise
> the conflict and require you to make it resolved.

I'll work to clarify the doc. What I'm proposing is this:

* user hijacks a read-only 'svn:needs-lock' file, edits it
* user tries to commit, gets error: "you need a lock!"
* user tries to lock, gets error: "you need to update!"
* user runs 'svn up':
     A. if file is mergeable, merge it.
     B. if file is unmergable, don't produce conflict, just back up
repos version.

So I *do* agree with you, regarding scenario (A) above. The deal is,
scenario (A) isn't very likely to happen. If the file were mergeable,
why did the admin put an 'svn:needs-lock' property on it? ;-)

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Oct 13 23:18:07 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.