On Wed, Apr 29, 2015 at 1:32 AM, Branko Čibej <brane_at_wandisco.com> wrote:
> On 29.04.2015 07:14, Nico Kadel-Garcia wrote:
>> On Wed, Apr 29, 2015 at 12:03 AM, Branko Čibej <brane_at_wandisco.com> wrote:
>>> On 29.04.2015 05:09, Nico Kadel-Garcia wrote:
>>>> On Tue, Apr 28, 2015 at 5:03 PM, Andrew Reedick <jreedick_at_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.
Received on 2015-04-29 14:11:12 CEST