[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Bug: Base checksum mismatch

From: Dave Lawrence <dlawrence_at_ad-holdings.co.uk>
Date: Thu, 29 May 2008 13:50:40 +0100

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

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


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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.