I agree that a warning would be more friendly in this situation.
"Warning: you're about to make an edited file go back to read-only state."
I mean, if the user wants to do it, sure, but it's a bit odd.
I think this is just a weird corner case that results from our design.
We deliberately designed {edited/not-edited}, {locked/unlocked} to be
independent variables. This is just bizarre fallout from that.
On 8/30/06, Malcolm Rowe <malcolm-svn-dev@farside.org.uk> wrote:
> 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
>
>
---------------------------------------------------------------------
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:53:43 2006