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