2011/8/19 Dennis Jones <djones_at_grassvalleysoftware.com>:
> Anyone? Really? No one knows anything about this?
>
> - Dennis
>
> "Dennis Jones" <djones_at_grassvalleysoftware.com> wrote in message
> news:j1shsm$lbu$1_at_dough.gmane.org...
>> Hi,
>>
>> I used rsvndump to dump a remote repository (because the server is running
>> an old version of SVN from before support for 'replay' was added). Now I
>> am trying to load the dump file into my local repository (VisualSVN 2.1.9)
>> and I'm getting the following error:
>>
>>
>> * adding path : trunk/SomePath/SomeFile.zip ...svnadmin: File already
>> exists: filesystem 'E:\Repositories\Archive\db', transaction '3186-2gi',
>> path 'trunk/SomePath/SomeFile.zip'
>>
>>
>> Interestingly, it looks like it fails at revision 3186, but a glance at
>> the output shows:
>>
>> ------- Committed revision 3186 >>>
>>
>> <<< Started new transaction, based on original revision 3187
>>
>> So why is the transaction for 3186 still there?
>>
>> This is my second attempt at doing this, and I got the same error (in the
>> same place) the first time. The dump file is almost 5GB in size and the
>> dump takes about 3 days to complete, so I'm not keen on doing it again,
>> and I doubt it will help anyway.
>>
>> Of course, I started with an empty repository on the local server, so it's
>> not like it already had data in it. So how can I get around this?
>>
>> Dennis
>>
>> I used rsvndump
What is that? You mean you performed the dump remotely using svnrdump
utility from some beta of svn 1.7 ? Does it work without replay
support on the server? (Isn't this utility essentially the same as
svnsync?)
I would suggest to compare what actually is in that revision in the
old and new repository. Do they match, or anything differs?
When you performed the dump, do you have read access to all paths in
the original repository?
Last time when I saw a message similar to yours was about a year ago,
when I tried to commit revision that had complicated moves and renames
/ replaces in it. The svn client (Tortoise) failed to commit it with a
similar message, but when I rerun the operation it committed
successfully. I still do not know what the cause was -- maybe some
ordering between operations. (I am using HTTPS access protocol + neon
+ it was some version of 1.6 or 1.5 several months after release),
Best regards,
Konstantin Kolinko
Received on 2011-08-19 18:11:40 CEST