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

Re: How to migrate just part of a repo to another server

From: Nico Kadel-Garcia <nkadel_at_gmail.com>
Date: Fri, 9 Sep 2011 07:27:43 -0400

On Thu, Sep 8, 2011 at 4:13 AM, Markus Schaber
<m.schaber_at_3s-software.com> wrote:
> Hi, Les,
>
> Von: Les Mikesell [mailto:lesmikesell_at_gmail.com]
>>
>> 2011/9/7 Thorsten Schöning <tschoening_at_am-soft.de>:
>> >
>> >> Would it work to start the dump at the revision of the move to the
>> >> current path (without --incremental) if I'm willing to lose the older
>> >> history that might have been in a cvs conversion?
>> >
>> > Is space a problem or why do you not just dump and load the whole
>> > repository and delete every path you don't need using svn? It may be
>> > the fastest solution and really preserves all history.
>>
>> There are currently a large number of projects in one repository.  The size
>> is still manageable but approaching being awkward to back up and
>> manipulate.   The point of splitting would be make the size for each
>> project reasonable - or perhaps to split out a project to be managed by a
>> group that should not have access to some of the other parts.
>> From the docs I would have expected giving a starting revision to svnadmin
>> dump to eliminate the history - and need for paths containing it - before
>> the specified point.  Is that not the case?
>
> I did not follow the thread, but did you have a look at svndumpfilter?
> http://svnbook.red-bean.com/en/1.6/svn.reposadmin.maint.html#svn.reposadmin.maint.filtering
>
> Best regards
>
> Markus Schaber

svndumpfilter is very awkward if components have been "copied" or
"moved" from one project to another, or if revisions exist that
manipulate multiple projects. That's particularly common when a site
policy change is made to list all .c files with svn:keywords, for
example, and not done project by project.

Frankly, I've given up on doing such complex migrations. There's a
point where you lock down the old repository in read-only mode, do an
svn export and svn import into a new repository, and start with a new
repository with a new uuid and a revised layout. The commit message on
the first revision can state where the old repository is, and if
absolutely necessayr, the old repository can use svn:externals to
point to the new one. But then it's *done*, and you have a chance to
set aside years of unnecessary logs and actual binary commits into a
separate repository and start *over*.
Received on 2011-09-09 14:28:25 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.