[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svnadmin: File not found: transaction on svnadmin load

From: B. Smith-Mannschott <benpsm_at_gmail.com>
Date: 2007-06-11 10:18:28 CEST

On 6/3/07, Herbert Gerngroß <Herbert.Gerngross@brz.gv.at> wrote:
> Hi,
> I am having problems converting one of my SVN repositories to SVN 1.4.
> I did a "svnadmin dump", created a new 1.4 repository with "svnadmin
> create" and tried to reload the dump with
> "svnadmin load mynewrepo < mydump".

I happen to know something about the history of this repository: I
created the dumpfile from which the SVN 1.3 repository was created.

A few months ago we migrated from our private SVN server to the
company-wide one. This repository was one of 3 resulting from
splitting up an existing repository on our private system.

The ancestral repository, which I'll call "A" ...

"A": /ERV/**

... was split into three parts:

"E": /ERV/**

"P": /publication/**

"N": /VJ/Nachhaltigkeit/**

1. An initial dumpfile containing all of A was created. (A.dump)

1a. All externals in A.dump were rewritten to refer to the new server
URL using revisionist.

2. From this dumpfilter was used to extract only /VJ/Nachhaltigkeit to
   produce repository "N".

3. Another pass of dumpfilter over A was used to create a dumpfile and
   then a repository containing everything except
   /VJ/Nachhaltigkeit. We'll call this temporary repository "T".

4. Two copies (i.e. cp -R) of the temporary repository "T" were made
   -> "E", "P"

5. "E" and "P" were modified through normal SVN commits in order to
   remove unwanted bits from HEAD (they are still in history).

6. "E" and "P" were dumped -> E.dump, P.dump

The repository under discussion here resulted from svnadmin load <
P.dump using svn 1.3.x

> Svnadmin then gives me the following error:
> ...
> <<< Started new transaction, based on original revision 5307
> ...
> adding path :
> published/WEBERV_20070320_Edikte_Kundmachung/ERV/FB/XMLSchema/ErvFdbMetadaten.xsd
> ... done.
> adding path :
> published/WEBERV_20070320_Edikte_Kundmachung/ERV/FB/XMLSchema/ErvFdbPayload.xsd
> ... done.
> svnadmin: File not found: transaction '5306-1', path
> 'published/WEBERV_20070320_Edikte_Kundmachung/ERV/Services/ERVNachricht.xsd'
> <<<
> adding path :
> published/WEBERV_20070320_Edikte_Kundmachung/ERV/Services/ERVNachricht.xsd
> First I thougth the repository was corrupted so I tried a "svnadmin
> verify" which says everything OK with the repo.
> So I looked at the revision 5307 in the old repository with "svnlook
> changed -r 5307 myrepo | grep Services"
> which gives me the following output:
> A
> published/WEBERV_20070320_Edikte_Kundmachung/ERV/Services/ERVNachricht.xsd
> A
> published/WEBERV_20070320_Edikte_Kundmachung/ERV/Services/ERVService.wsdl
> ...
> A published/WEBERV_20070320_Edikte_Kundmachung/ERV/ServicesÜST/
> A published/WEBERV_20070320_Edikte_Kundmachung/ERV/ServicesÜST/ERV.xsd
> ...
> A published/WEBERV_20070320_Edikte_Kundmachung/ERV/Services/
> The directory ERV/Services is added AFTER the file
> ERV/Services/ERVNachricht.xsd (the file which gives the error) was
> added.
> I found a similar problem at
> http://svn.haxx.se/users/archive-2006-04/0401.shtml.
> I think I can solve my problem if I can manipulate the dumpfile (which
> is 900MB) so that the directory is added before the file.
> Is it possible to manipulate a svn-dumpfile by hand?
> I don't know the format of svn-dumps.
> Is it enough to just cut out the
> Node-path: published/WEBERV_20070320_Edikte_Kundmachung/ERV/Services
> Node-kind: dir
> Node-action: add
> Prop-content-length: 10
> Content-length: 10
> and place it before the
> Node-path:
> published/WEBERV_20070320_Edikte_Kundmachung/ERV/Services/ERVNachricht.xsd
> Node-kind: file
> Node-action: add
> Prop-content-length: 10
> Text-content-length: 6179
> Text-content-md5: 4b67d3918d3647d1e280efecfafe476d
> Content-length: 6189
> ?

Editing dump files by hand, particularly of that size, is tricky business.

> What does Prop-content-length: 10 and Content-length: 10 mean?
> Could I use svndumpfilter to do the job?

Prop-content-length: 10 means that there are 10 bytes of property data
following the last header.

In this case:
  P R O P S - E N D [line-feed]

Content-length: 10 means that the total number of bytes of content
following the last header is 10 bytes. The content contists of the
properties followed by the file contents ("text") associated with the

In this case, Prop-content-length == Content-length, implying that
Text-content-length == 0.

For more on the dumpfile format see also:


I haven't got an easy solution to your problem, but here are some
things I would in order to get more information:

1. You can use ``svnadmin dump --revision X:Y`` to dump only parts of
   the history. Since the problem is in revision 5307 you could
   create three dump files:

   svnadmin dump --revision 0:5306 REPOS > A.dump
   svnadmin dump --revision 5307:5307 REPOS > B.dump
   svnadmin dump --revision 5308:HEAD REPOS > C.dump

   Then try loading A, then B, then C.

   If that doesn't work, try loading A, create that pesky Services
   directory, then try to continue on with B, C.

2. You could try editing the dump file, now that you know the meanings
   for Content-length and friends.

3. You could write use revisionist to do this edit for you, though
   you'd have to write a generator of medium complexity in python. (I
   could help you out here since I know my way around revisionist.)

// Ben Smith-Mannschott
Received on Mon Jun 11 10:39:25 2007

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.