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

Re: svn commit: r13308 - branches/locking/subversion/libsvn_fs_base

From: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2005-03-08 22:42:21 CET

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

But at the moment, we don't seem to be able to lock a schedule-add file:

[sussman@BenBook:~/scratch/wc]$ touch newfile
[sussman@BenBook:~/scratch/wc]$ svn add newfile
A newfile
[sussman@BenBook:~/scratch/wc]$ svn lock newfile -m "lock new file"
subversion/libsvn_ra_dav/util.c:365: (apr_err=160041)
svn: Path '/newfile' doesn't exist in HEAD revision.

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,

I bet this is a simple bug to fix: if locking a schedule-add file,
just don't send the working-revnum.

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Mar 8 22:47:38 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.