You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by geoff <ot...@0x29a.org.uk> on 2005/09/16 16:56:31 UTC
wc in "the future", no error on commit, feature request?
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?
--
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
Re: wc in "the future", no error on commit, feature request?
Posted by geoff <ot...@0x29a.org.uk>.
On Fri, 23 Sep 2005 17:18:00 +0100, geoff <ot...@0x29a.org.uk> wrote:
<snip>
>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
No, this isn't a Tortoise issue either. My apologies to the Tortoise devs.
This script illustrates the situation:
---------- start script
#!/bin/bash
set -v
HERE=`pwd`
REPOPATH=$HERE
THEREPO=$REPOPATH/myrepo
WCPATH=$HERE
THEWC=$WCPATH/mywc
rm -rf $THEREPO
rm -rf $THEWC
# step 1
svnadmin create --fs-type fsfs $THEREPO
# step 2
svn checkout file:///$THEREPO $THEWC
# step 3
touch $THEWC/file1
svn add $THEWC/file1
echo "mod 1" > $THEWC/file1
# step 4
svn update $THEWC
svn commit -m "v1" $THEWC
# step 5
svnadmin dump $THEREPO > $WCPATH/dumpofv1
# step 6
touch $THEWC/file2
svn add $THEWC/file2
# step 6a
echo "mod 2" > $THEWC/file1
# step 7
svn update $THEWC
svn commit -m "v2" $THEWC
# step 8
rm -rf $THEREPO
svnadmin create --fs-type fsfs $THEREPO
cat $WCPATH/dumpofv1 | svnadmin load $THEREPO
# step 9
echo "mod 3" >> $THEWC/file1
svn commit -m "bogus v2" $THEWC
# step 10
svn update $THEWC
---------- end script
This produces the output:
[...]
# step 9
echo "mod 3" >> $THEWC/file1
svn commit -m "bogus v2" $THEWC
Sending mywc/file1
Transmitting file data .svn: Commit failed (details follow):
svn: Base checksum mismatch on 'file1':
expected: d0b7e79d4a6ccfcf328b1d9b4a64279c
actual: f14c077f10dcaad0ce42856b52cb50f4
# step 10
svn update $THEWC
svn: No such revision 2
If step 6a is commented out we get:
[...]
# step 9
echo "mod 3" >> $THEWC/file1
svn commit -m "bogus v2" $THEWC
Sending mywc/file1
Transmitting file data .
Committed revision 2.
# step 10
svn update $THEWC
svn: Working copy path 'file2' does not exist in repository
The mod3 change to file1 is committed if and only if the base content of file1 lines up
with the contents of the repo.
The situation my users were in was that of step 6a commented: commits proceeded until an
update was performed.
While mildly confusing to userss who don't do an update before a commit, this approach
seems maximally protective of changes in (broken) working copies.
--
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
Re: wc in "the future", no error on commit, feature request?
Posted by geoff <ot...@0x29a.org.uk>.
On Fri, 16 Sep 2005 17:56:31 +0100, geoff <ot...@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