On Fri, 16 Sep 2005 17:56:31 +0100, geoff <ot0006@0x29a.org.uk> wrote:
>I realise this is a pathological case and the obvious answer is "don't do that", but I'd
>like to raise the issue anyway.
>
>Single-user repo running Subversion 1.1 on FC4, Win32 client
>
>After a catastrophic failure took out both the repo and some of the later backups, rev nn
>was restored in the belief this was the latest version, when in fact the latest was rev
>nn+2.
>
>Revs nn+1 and nn+2 had added some files.
>
>The user with a wc at rev nn+2 went on to do some commits before finally doing an update.
>The commits succeeded, the update failed with
>
>Working copy path '[path]' does not exist in repository
>
>naming one of the added files. Which is correct, but by then we're some way into an
>unfortunate situation. In this case it wasn't helped by the user taking ~4 months to get
>round to doing an update, by which time memory of the failure had faded.
>
>After some headscratching the relevant data was copied to a new wc at the new head and
>it's all sorted out now.
>
>However, the administrator's job in this case might be simplified if commits from a wc
>with any member at a higher rev than head were blocked, thus preventing the problem
>getting any worse than it was already.
>
>Is this a reasonable feature request?
Further testing reveals this to be a TortoiseSVN issue. When the scenario is recreated
using a script and the SVN command line client, we see :
svn: No such revision 3
Sending testwcs/mytest/file1
Transmitting file data .svn: Commit failed (details follow):
svn: Base checksum mismatch on 'file1':
expected: c2ff4b361ea9984f93b6a1e2a5c77a92
actual: f14c077f10dcaad0ce42856b52cb50f4
Tested at 0.31, 1.1.3, 1.1.4.
--
best,
geoff
regrettably the email address above will bounce
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Sep 23 18:23:18 2005