On Wed, Apr 29, 2015 at 1:32 AM, Branko Čibej <br...@wandisco.com> wrote: > On 29.04.2015 07:14, Nico Kadel-Garcia wrote: >> On Wed, Apr 29, 2015 at 12:03 AM, Branko Čibej <br...@wandisco.com> wrote: >>> On 29.04.2015 05:09, Nico Kadel-Garcia wrote: >>>> On Tue, Apr 28, 2015 at 5:03 PM, Andrew Reedick <jreed...@incomm.com> >>>> wrote: >>>>> Does anyone have any tips on how to upgrade a very old repo? The >>>>> db/format lists "1". A 1.8 svn client cannot hotcopy, dump or "svnadmin >>>>> upgrade" such an old repo, all of which fail with "svnadmin: E720002: >>>>> Can't open file 'devel\db\current': The system cannot find the file >>>>> specified." >>>>> >>>>> Do I need find a really old svn client (1.3?) and upgrade? Do I need to >>>>> manually create the db/current file? >>>>> >>>>> >>>>> Supposedly , a format of "1" is from pre-svn 1.0. >>>>> https://svn.apache.org/repos/asf/subversion/trunk/subversion/libsvn_repos/repos.h >>>>> -> "Formats 0, 1 and 2 were pre-1.0." >>>> Why can't you do a fresh working copy, and copy all files except those >>>> in '.svn' subdirectories? >>> Without db/current, he can't perform a checkout, and if he could and >>> just copied the file, he'd be throwing away all history. >> >> What? "hotcopy", "dump", and "svnadmin upgrade" are all operations on >> the repository itself. The database *of the repository* is irrelevant >> to fresh checkouts, as long as they can speak any relevant network >> protocols associated with the old service. > > You proposed copying "all files except those in .svn directories" from a > fresh checkout. This implies actually doing a checkout, which you can't > do if your repository is corrupt, and it's corrupt if it's a FSFS repo > without a db/current file. It's irrelevant whether you're doing a > checkout from a local repository or over the network or via git-svn or > whatever.
I was assuming his core problem was the age of the repository and finding compatible server side tools to help with the upgrade. I also admit, myself, that when migrating old repositories, I could generally not care less about the history, which has often become quite cluttered with old mistakes and accidental binary commits. If it's genuinely corrupt, that's a distinct issue from "all my current tools are unable to read such an old repository", which is what it sounded like. I'll be curious to see if Philip Martin's suggestion to use 'svnadmin recover' helps out with that. I'd also make *absolutely sure* to use "rsync -a" or "cp -a" on Linux systems to copy the repository somewhere else, and only touch the *copy*, until this is straightened out.
