Mailing-List: contact users-help@subversion.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (athena.apache.org: domain of sudakov@sibptus.tomsk.ru
 designates 212.73.124.8 as permitted sender)
Date: Fri, 7 Jan 2011 19:57:20 +0600
From: Victor Sudakov <sudakov@sibptus.tomsk.ru>
To: users@subversion.apache.org
Subject: Re: "svnadmin load" a huge file
Message-ID: <20110107135720.GA39540@admin.sibptus.tomsk.ru>
References: <20101231030732.GA52945@admin.sibptus.tomsk.ru>
 <20101231090740.GA27220@daniel3.local>
 <20101231150933.GA59535@admin.sibptus.tomsk.ru> <4D1DF857.5070605@gmail.com>
 <20101231161546.GA69395@admin.sibptus.tomsk.ru> <4D2270DD.5070601@gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4D2270DD.5070601@gmail.com>
User-Agent: Mutt/1.4.2.3i
Organization: AO "Svyaztransneft", SibPTUS

Brian Brophy wrote:
> >  
> >>I migrated a large CVS repository (25-50 GB) to SVN years ago on SVN 
> >>1.3.  Our repo had many sections (projects) within it.  We had to 
> >>migrate each project independently so that it's team could coordinate 
> >>when they migrated to SVN.  As such, I dumped each project when ready 
> >>and then svnadmin loaded each dump into it's own path/root (so as not to 
> >>overwrite anything previously loaded and unrelated to this project's 
> >>import).
> >>
> >>So, you can do it by controlling which path/portion of CVS you use 
> >>cvs2vn to create the dump file from.
> >>    
> >
> >The CVS repository in question (with the size 54M with 17751 files) is
> >exactly one project. It's the history of a geographical DNS zone for
> >more than 10 years.

> Fair enough, the same pattern is still applicable.  For example, in our 
> CVS repo what separated one "project" from another was basically a 
> root-level folder.
> 
> In kind, you could similarly use cvs2svn to "chunk/dump" subdirectories 
> at a time.
> 
> For example, if in CVS you have something like:
> /Folder1
> /Folder2
> /Folder3
> 
> ... you run cvs2svn three times, once for each subdirectory, producing 
> folder1.dump, folder2.dump, and folder3.dump respectively.
> 
> Then, svnadmin load each individually:

It would be fine if the project in question did not contain almost all
the files in one directory. You may call the layout silly, but CVS does
not seem to mind. OTOH, I would have distributed the files over
several subdirectories, but CVS does not handle moving files well.

I wonder if cvs2svn is to blame that it produces a dump svnadmin
cannot load. Or I am always risking that "svnadmin dump" may one day
produce a dump a subsequent "svnadmin load" will be unable to swallow?

I mean, if by hook or by crook, by using third party utilities like
svndumptool, I will eventually be able to convert this project from
CVS to SVN. Is there a chance that a subsequent dump will be again
unloadable?

-- 
Victor Sudakov,  VAS4-RIPE, VAS47-RIPN
sip:sudakov@sibptus.tomsk.ru