On Tue, 12 Apr 2005, D.J. Heap wrote:
> The first issue is when I lock an out-of-date file (especially with the
> needs-lock property on). The file is not currently locked by anyone
> else (and if needs-lock was on, it is changed to editable from
> read-only) so I get the lock, edit the file, and fail to commit because
> I'm out of date. This seems to defeat the purpose of the lock in the
> first place (to prevent wasting my time on unmergeable changes).
> Shouldn't there at least be some notification at lock time that the file
> is out of date?
>
> Here's a transcript (D:\Temp\trwc is a test working copy, D:\Temp\trwc2
> is a 2nd test working copy of the same repo):
>
> D:\Temp>svn lock trwc\file.txt
> 'file.txt' locked by user 'dj'.
>
> D:\Temp>notepad trwc\file.txt
>
> D:\Temp>svn commit -m "test" trwc
> Sending trwc\file.txt
> Transmitting file data .
> Committed revision 3.
>
> D:\Temp>svn lock trwc2\file.txt
> 'file.txt' locked by user 'dj'.
>
> D:\Temp>notepad trwc2\file.txt
>
> D:\Temp>svn commit -m "test" trwc2
> Sending trwc2\file.txt
> Transmitting file data .svn: Commit failed (details follow):
> svn: Out of date: 'file.txt' in transaction '3-1'
>
> D:\Temp>
>
> This transcript is from Windows, but I tested and got the same results
> on Linux.
>
I've tried to reproduce this over ra_local using both fsfs and fs_base,
but without success. I get errors about the file being out-of-date when
trying to lock a not-up-to-date file (even with svn:needs-lock set, of
course). Could you be more specific regarding ra layer and fs type and so
on?
> The second issue is probably Windows only -- assuming the needs-lock
> property was on the file and you run the above transcript, if you issue
> an 'update' and get a conflict, the file.txt is read-only and cannot be
> edited. And on Windows it cannot be reverted either -- the revert fails
> with 'Access denied' due to the read-only flag. It seems like a
> conflict should leave the file editable, and revert (and possibly other
> commands?) need to pay attention to the needs-lock property and remove
> read-only-ness when necessary.
>
You're probably right regarding revert; it should remove the read-only
flag if svn:needs-lock is set.
Regarding a conflicted file, you should have to grab a new lock to resolve
a conflict. If you don't have a lock, the file should be read-only to
remind you about that. Maybe I'm missing something from your explanation
here?
> So, are these real issues or is my understanding incomplete? I can look
> deeper into them this weekend if they are real issues and try coming up
> with fixes.
>
Thanks for testing,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Apr 13 08:26:24 2005