On Tue, 8 Mar 2005, Ben Collins-Sussman wrote:
> On Mar 8, 2005, at 3:28 PM, Philip Martin wrote:
> >
> > http://svn.haxx.se/dev/archive-2005-02/0070.shtml
> >
> > I was told that locks apply to pathnames and that locking schedule add
> > files should be possible, so just add "create file 'foo/bar'" before
> > the "lock 'foo/bar'" step.
> >
>
> Whoops, sorry for the confusion. I must have been speaking about
> features I *wished* for, not things we've actually planned or
> implemented. libsvn_fs certainly supports locks on nonexistent paths;
> it's just a table of metadata that associates pathnames with svn_lock_t
> structures.
>
> But at the moment, we don't seem to be able to lock a schedule-add file:
>
...
>
> Tracing through the code, I think I see the problem. The client is
> passing a working-rev of 0 to the server, and libsvn_fs is using that
> value to do an out-of-dateness check on the object! libsvn_fs tries to
> look up the (0, path) and then get that node's created-rev. An invalid
> revnum is returned, and then the error above is returned. (You can see
> this code in the locking branch, libsvn_fs_base/lock.c,
> txn_body_lock()).
>
> 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.
regards,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Mar 9 08:16:00 2005