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

Re: Locking issues

From: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2005-04-13 14:50:49 CEST

On Apr 12, 2005, at 9:55 PM, Brian W. Fitzpatrick wrote:

> On Apr 12, 2005, at 9:53 PM, Greg Hudson wrote:
>> On Tue, 2005-04-12 at 22:33, Brian W. Fitzpatrick wrote:
>>> Hmm. Interesting point! I would say that in order to lock a file in
>>> a
>>> working copy, the working copy should *have* to be up to date. I
>>> can't
>>> recall going over this case, but it seems like requiring an
>>> up-to-date
>>> wc is The Right Thing To Do.
>> We went over this at great length early on. Karl wanted "svn lock
>> filename" to update the file; other people (including me) wanted it to
>> simply fail if the file wasn't up to date. I believe my side won the
>> argument, and the planned machinery was that svn_ra_lock() would take
>> a
>> file version number (optional) so that the server could verify that
>> the
>> file is up to date when locking it. I don't know how we got
>> off-course.
> Ah yes! Now I remember the debate, and yes, we must have gotten
> off-course somewhere.

If this is really reproducible, then it's a major bug. 'svn lock'
sends the file's working revnum all the way over the network into
svn_fs_lock(), which then does an out-of-dateness check before creating
the lock. Don't we have a python test for this?

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Apr 13 14:52:46 2005

This is an archived mail posted to the Subversion Dev mailing list.