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

p42svn | svnadmin load gives bogus 'File already exists' error

From: Ted Burghart <ted_at_tedb.net>
Date: Tue, 26 May 2009 17:26:29 -0400


I'm trying to move my SCM repository from perforce to svn and am being
tripped up by what looks to me like a spurious error.

My environment:
- Perforce server: P4D/FREEBSD60X86/2007.3/152469 running on FreeBSD
7.0-RELEASE-p1 i686.
- Subversion server: subversion-1.5.5 OpenBSD package on OpenBSD 4.5-
stable i686.
- p42svn.pl v0.21 on OS X 10.5.7 Intel with Perl 5.8.8,
p4api-2008.2.199044 and p4perl-2008.2.

Fortunately this repository isn't huge so I can experiment with the
full dump and load at will.

I create the dump with

    ./p42svn.pl --branch //depot/prj=trunk/prj > /shared-mounts/

And attempt the load with

    rm -rf repos-name
    svnadmin create repos-name
    svnadmin load repos-name < /shared-mounts/scratch/p4repos2svn.dump

Well into the load I get

    <<< Started new transaction, based on original revision 50
    svnadmin: File already exists: filesystem 'repos-name/db',
transaction '49-1d', path 'trunk/prj/www/domain-name/elements/err/'
         * adding path : trunk/prj/www/domain-name/elements/err/ ...

To cover a few questions that might come up:
- Whether I use a shared network directory as shown or scp or rsync
the dump file from the machine doing the extract to the machine doing
the load makes no difference.
- Combinations of --user, --munge-keywords and --convert-eol options
to p42svn have no effect on the error.
- Performing the load as root or as the user that runs svnserve has no
effect on the error.
- Performing the load with svnserve running or not has no effect on
the error.
- I've seen reference in this list to issues with duplicate revision
numbers and have checked the dump file carefully - I do not find any
such problems.

I am not expert in svn dump files, but perusal of the file suggests a
pretty straightforward format and I find no problems with munged-up
transactions. The first line of the dump file is "SVN-fs-dump-format-
version: 1", which I presume identifies the file's schema.

The point at which the load fails seems to be the first point at which
the referenced path is mentioned, so it clearly should not yet exist:

# grep -n -A8 -B1 trunk/prj/www/domain-name/elements/err/ /shared-
130581:Node-path: trunk/prj/www/domain-name/elements/err/
130582-Node-kind: dir
130583-Node-action: add
130584-Prop-content-length: 10
130585-Content-length: 10
130589:Node-path: trunk/prj/www/domain-name/elements/err/error-403.shtml
130590-Node-kind: file
130591-Node-action: add
130592-Text-content-length: 2131
130593-Text-content-md5: 3f53ff1af089de062bd9df2d0c48069c
130594-Prop-content-length: 10
130595-Content-length: 2141

130655:Node-path: trunk/prj/www/domain-name/elements/err/error-404.shtml
130656-Node-kind: file
130657-Node-action: add
130658-Text-content-length: 2125
130659-Text-content-md5: 20997b158acc3c1db5d8496166574e76
130660-Prop-content-length: 10
130661-Content-length: 2135
As you can see, the directory in question and the two files in it were  
added once and have not been touched since.  I am at a loss as to  
where I go from here and would greatly appreciate any assistance  
  - Ted
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-05-26 23:41:55 CEST

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