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

Re: locking schedule-add files

From: Philip Martin <philip_at_codematters.co.uk>
Date: 2005-03-09 21:29:55 CET

Ben Collins-Sussman <sussman@collab.net> writes:

> On Mar 9, 2005, at 1:17 AM, Peter N. Lundblad wrote:
>>>
>>> I bet this is a simple bug to fix: if locking a schedule-add file,
>>> just don't send the working-revnum.

And make sure the FS only allows that for non-existant paths, for
existing paths the revnum must be passed and must be up to date.

>>>
>> It is not as simple as one might think. We need a way to say "this
>> path shouldn't exist" when you lock it. Else you can lock an
>> existing path and think it is your schedule add path you locked.

We can do that via the revnum: a non-zero revnum means the path must
exist, a zero revnum means the path must not exist.

[snip]

> Hm, after thinking about your explanation, I think I'm actually
> *against* this feature now.
>
> The goal of the locking feature has always been "to prevent people
> from wasting time on unmergeable changes." Unless we make 'svn add
> foo.c' unconditionally do a network check (ugh!), locking a
> schedule-add file will do absolutely nothing to further the goal. It
> would do nothing but create a false sense of security.
>
> Additionally, I think it's pretty rare for two people to each create
> identically-named, unmergeable files without realizing. Our current
> locking design covers the 95% case (two people trying to edit an
> existing unmergeable file),

Locking schedule add files does more than prevent identically named
files, it also prevents umergeable changes to the directory structure.
Locking a schedule add file will prevent anyone else adding or
deleting any of the parents of the schedule add file, things that
would cause a conflict in the working copy.

> and I think we'd get very little benefit
> trying to come up with a twisted solution for schedule-add files.

Twisted?

-- 
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Mar 9 21:31:49 2005

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.