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