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