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

Re: Dealing with very old repo format (version 1)

From: Branko Čibej <brane_at_wandisco.com>
Date: Wed, 29 Apr 2015 07:32:13 +0200

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.

-- Brane
Received on 2015-04-29 12:14:01 CEST

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.