So I was just playing around with the lock/unlock commands, and I'm
a bit surprised about one thing: why can you unlock a file that has
svn:needs-lock set and that also has uncommitted changes?
By definition, this is almost certainly an unmergable file - hence the
requirement to get a lock before changing it - and you've just changed it,
but not committed. Why wouldn't we fail the unlock, or at least warn,
in that situation?
I guess that this isn't a big deal, since I can't imagine a situation
where you could do anything to lose work for anyone else (unless they're
also doing the same silly thing), but it does seems odd that we allow
this currently.
Transcript:
$ svnadmin create repo
$ svn co file://`pwd`/repo wc
Checked out revision 0.
$ touch wc/foo
$ svn add wc/foo
A wc/foo
$ svn ps svn:needs-lock x wc/foo
property 'svn:needs-lock' set on 'wc/foo'
$ svn ci wc/foo -m 'add foo'
Adding wc/foo
Transmitting file data .
Committed revision 1.
$ ls -la wc/foo
-r--r--r-- 1 malcolm users 0 2006-08-30 21:53 wc/foo
$ svn lock wc/foo
'foo' locked by user 'malcolm'.
$ ls -la wc/foo
-rw-r--r-- 1 malcolm users 0 2006-08-30 21:53 wc/foo
$ echo 'editing this unmergable file' > wc/foo
$ svn unlock wc/foo
'foo' unlocked.
$ ls -la wc/foo
-r--r--r-- 1 malcolm users 29 2006-08-30 21:54 wc/foo
$ svn st wc
M wc/foo
Regards,
Malcolm
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Aug 30 23:30:44 2006