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

locking schedule-add files (was Re: svn commit: r13308)

From: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2005-03-09 15:28:38 CET

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.
> 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.
> A problem with being able to lock schedule add files is that it might
> make
> people disappointed. If the user Hulda schedule-adds a path, then
> locks it
> and starts working. Then Hildur (another Swedish user) schedule-ads the
> same pathname in her WC and starts working. Then, Hulda commits her
> add.
> Hildur tries to commit and gets a conflict and has wasted her time. OK;
> this will happen without being able to lock schedule-add files. The
> problem is that we can't enforce the locking like we can with
> svn:needs-lock. So it wouldn't prevent what locks are intended to
> prevent,
> wasted work on unmergable files.
> If users really want this feature, after understanding the
> limitations, we
> could add it. But I think it is low priority.

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), and I think we'd get very little benefit
trying to come up with a twisted solution for schedule-add files.

I think the best thing to do is just make 'svn lock' deliberately error
out on a schedule add file. The message would be something like, "Only
files in already in the repository can be locked."

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Mar 9 15:30:02 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.