[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: David Glasser <glasser_at_davidglasser.net>
Date: Wed, 28 May 2008 11:26:47 -0700

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.)


David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/
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-28 20:27:13 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.