You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Yves Martin <ym...@gmail.com> on 2015/10/01 10:19:22 UTC
svnrdump produce a strange dump file
Hello,
I have a Subversion 1.6.17 server running on Debian Linux and access
through HTTPS.
I used both Subversion 1.8.10 and Subversion 1.9.2 to produce a partial
dump of the repository:
svnrdump dump -r 51686:77787
https://myhost/subversion/repository/PROJECT/trunk/amodule | gzip >
amodule.dump.gz
I got a version 3 dump which has the following trouble: almost all files
content begins with a strange "SVN" binary sequence.
Here is an excerpt of the dump itself for such a file:
Node-path: trunk/amodule/pom.xml
Node-kind: file
Node-action: add
Prop-delta: true
Prop-content-length: 10
Text-delta: true
Text-content-length: 3271
Text-content-md5: 1e6f17c85e486bfec9b0f71291cad435
Content-length: 3281
PROPS-END
SVN^@^@^@<99>9^C<99>9<80><99>9<project xmlns="
http://maven.apache.org/POM/4.0.0" xmlns:xsi="
http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd">
<parent>
As a result, load operation fails as Text-content-md5 cannot be verified.
According to documentation svnrdump is compatible with Subversion server
1.4 for dump. What is wrong ?
Thank you in advance for your help
--
Yves Martin
Re: svnrdump produce a strange dump file
Posted by Philip Martin <ph...@wandisco.com>.
Yves Martin <ym...@gmail.com> writes:
> I got a version 3 dump which has the following trouble: almost all files
> content begins with a strange "SVN" binary sequence.
That's normal: dump is a binary format and that is the start of some
data in svndiff format.
> As a result, load operation fails as Text-content-md5 cannot be verified.
Load will handle svndiff format so that is not the cause of the failure.
> According to documentation svnrdump is compatible with Subversion server
> 1.4 for dump. What is wrong ?
Your dump file may be corrupt but you have not provided enough details
for us to be able to determine what caused it. You could start by
giving us the commands you used to dump and load and the error message
you received. If you are manipulating the dump file and assuming that
it is a text file then you may corrupt it.
--
Philip Martin
WANdisco
Re: svnrdump produce a strange dump file
Posted by Dave Huang <kh...@azeotrope.org>.
On Oct 1, 2015, at 8:29, Nico Kadel-Garcia <nk...@gmail.com> wrote:
>
> On Thu, Oct 1, 2015 at 4:19 AM, Yves Martin <ym...@gmail.com> wrote:
>> Hello,
>>
>> I have a Subversion 1.6.17 server running on Debian Linux and access through
>> HTTPS.
>>
>> I used both Subversion 1.8.10 and Subversion 1.9.2 to produce a partial dump
>> of the repository:
>
> *Why*? If you have a subversion 1.6.17 server, why wouldn't you use
> the the local svnadmin dump command for maximum binary compatibility?
> I'm not saying it shouldn't work, just wondering why you're even
> bothering.
I interpreted "access through HTTPS" as meaning the *only* access is through HTTPS. svnadmin requires a local shell on the server.
Re: svnrdump produce a strange dump file
Posted by Nico Kadel-Garcia <nk...@gmail.com>.
On Fri, Oct 2, 2015 at 3:26 AM, Yves Martin <ym...@gmail.com> wrote:
> Hello,
>
> The problem I face now when using "svnadmin dump" is "svndumpfilter:
> E200003: Invalid copy source path' when selecting the three /trunk modules I
> am interested in.
> Such a problem "svnrdump" does not produce.
>
> Thank you in advance for your help
> --
> Yves Martin
Oh, my. Stop right there. Remember how svnrdump didn't work? Now
you're adding another peoblem, picking and choosing individual
components with svndump. Do a test svnadmin dump, and reload of
everything to a new repo, *first*. This helps eliminate confusion and
verifies that the basic process is workable.
*Then* consider optimizing. Dump from the *new* repo, with the latest
tools, and see if picking and choosing works there. And in general,
avoid picking and choosing with svnadmin dump: it's never worked that
well if components were moved among various target directories, if
"trunk" directories got renamed or re-arranged, etc.
Frankly, also, if you're planning on re-arranging the material and
putting up a pruned repository, why are you bothering with dumps? Why
not save yourself some grief, lock the original content in a final
tag, do an export and import, and start with a completely clean new
history?
Re: svnrdump produce a strange dump file
Posted by Yves Martin <ym...@gmail.com>.
Hello,
The problem I face now when using "svnadmin dump" is "svndumpfilter:
E200003: Invalid copy source path' when selecting the three /trunk modules
I am interested in.
Such a problem "svnrdump" does not produce.
Thank you in advance for your help
--
Yves Martin
Re: svnrdump produce a strange dump file
Posted by Yves Martin <ym...@gmail.com>.
On Thu, 2015-10-01 at 09:29 -0400, Nico Kadel-Garcia wrote:
> If you're doing an rsync or scp to a remote system and doing the
> svndump there, you're running the risk of transferring content in the
> middle of an atomic operation and thus confusing the system.
>
> > svnrdump dump -r 51686:77787
> > https://myhost/subversion/repository/PROJECT/trunk/amodule | gzip >
> > amodule.dump.gz
> Does anyone actually use "svnrdump"? I've not explored it myself, but
> don't see where it's a big advantage over a remote "ssh hostname
> svnadmin dump" command, which avoids the kind of confusion I just
> described. I'd start there, to avoid certain levels of uncertainty and
> incompatibility with an out of date and no longer supported Subversion
> release with a more modern tool that may not have been thoroughly
> tested with it.
What is interesting with svnrdump is that it is efficient to generate a
"partial" dump, in term of revision range and selected path !
What "svnadmin dump" is not able to do without scanning a large part of
the full repository (10 GiB)...
Indeed you were right. As there is no merge tool for format 3 dumps, I
decided to rsync over ssh the repository and run svnadmin dump on my
workstation to avoid disturbing users.
Thank you for that tip
--
Yves Martin
Re: svnrdump produce a strange dump file
Posted by Nico Kadel-Garcia <nk...@gmail.com>.
On Thu, Oct 1, 2015 at 4:19 AM, Yves Martin <ym...@gmail.com> wrote:
> Hello,
>
> I have a Subversion 1.6.17 server running on Debian Linux and access through
> HTTPS.
>
> I used both Subversion 1.8.10 and Subversion 1.9.2 to produce a partial dump
> of the repository:
*Why*? If you have a subversion 1.6.17 server, why wouldn't you use
the the local svnadmin dump command for maximum binary compatibility?
I'm not saying it shouldn't work, just wondering why you're even
bothering.
If you're doing an rsync or scp to a remote system and doing the
svndump there, you're running the risk of transferring content in the
middle of an atomic operation and thus confusing the system.
> svnrdump dump -r 51686:77787
> https://myhost/subversion/repository/PROJECT/trunk/amodule | gzip >
> amodule.dump.gz
Does anyone actually use "svnrdump"? I've not explored it myself, but
don't see where it's a big advantage over a remote "ssh hostname
svnadmin dump" command, which avoids the kind of confusion I just
described. I'd start there, to avoid certain levels of uncertainty and
incompatibility with an out of date and no longer supported Subversion
release with a more modern tool that may not have been thoroughly
tested with it.