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

[Ben Collins-Sussman <su...@collab.net>]

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

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

["Peter N. Lundblad" <pe...@famlundblad.se>]

On Thu, 10 Mar 2005, Daniel Patterson wrote:

> Ben Collins-Sussman wrote:
> > 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."
>
>    Does this include renaming files?
>
>    So two questions:
>      1) Is it ok to rename a file that's locked?

That is an add and a delete. The file scheduled for deletion will remain
locked. The added file will not.

>      2) Is it ok to lock a file that's renamed?
>
Nope. That's locking a schedule add file.

Regards,
//Peter

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

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

[Daniel Patterson <da...@danpat.net>]

Ben Collins-Sussman wrote:
> 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."

   Does this include renaming files?

   I.e. which of the following (if either) will generate an error:

    $ svn co file:///repos/trunk
    U trunk/readme.txt
    ....
    $ cd trunk
    $ svn lock readme.txt
    svn: readme.txt locked with token XYZ
    $ svn mv readme.txt readme2.txt
    ???? what happens here is it ok to rename a locked file?

   or

    $ svn co file:///repos/trunk
    U trunk/readme.txt
    ....
    $ cd trunk
    $ svn mv readme.txt readme2.txt
    A readme2.txt
    D readme.txt
    $ svn lock readme2.txt
    ???? according to your satement above, this'll throw an error,
         but should it?

   So two questions:
     1) Is it ok to rename a file that's locked?
     2) Is it ok to lock a file that's renamed?

daniel

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: locking schedule-add files

[Philip Martin <ph...@codematters.co.uk>]

Ben Collins-Sussman <su...@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