David Glasser wrote:
> On Wed, May 28, 2008 at 4:41 AM, Ronny Voelker <ronny.voelker_at_elaxy.com> wrote:
>> Daniel Shahaf writes:
>>
>>> I can't reproduce the highlighted bit with trunk-r31016. I did
>>>
>>> % svn lock f
>>> svn: warning: Lock failed: newer version of '/f' exists
>>> % svn up
>>> U f
>>> Updated to revision 2.
>>> % svn cat f
>>> (shows changes from the last commit)
>>> % cat f
>>> (shows changes from the last commit)
>>> % svn lock f && svn ci f
>>> (works)
>>>
>> Yes, that's what I said already. ;)
>> AFAIK it's not possible to reproduce this bug with the svn-command-line-client.
>> It's a specific feature of TSVN:
>> If a newer version exists when you try to lock a file, TSVN doesn't abort.
>> Instead it asks you, if you want to update the file and try again.
>> If you agree, it updates it automatically and retries the lock.
>>
>> Only if agree to updates the file automatically, it is not updated properly.
>> If you decline, update the file manually and then retry, everything works fine.
>
> Sounds like you should report this on the TortoiseSVN mailing list,
> then. (If the problem turns out to be in our libraries, the TSVN devs
> can point that out with the specific APIs.)
>
> --dave
>
>
1) It has been reported on TSVN list already
http://svn.haxx.se/tsvnusers/archive-2008-05/0127.shtml
2) It can be reproduced on the command line, as we found infact it was
nothing to do with locking but to do with
svn up file --depth empty
http://subversion.tigris.org/servlets/BrowseList?list=users&by=thread&from=653886
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-05-29 14:55:18 CEST