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

Re: Question about splitting/merging repository

From: Jean-Yves Avenard <jyavenard_at_gmail.com>
Date: Fri, 24 Jun 2011 11:01:46 +1000

On 24 June 2011 05:33, Ryan Schmidt <subversion-2011a_at_ryandesign.com> wrote:
> You should be able to meet the "same revision numbers across both repositories" goal by inserting empty revisions for the ones not applicable to the projects in each new repo (the tools should do this for you when you use the right arguments). But you will not be able to meet the goal of being able to switch old working copies from the old monolithic repository to either of the new repositories. A working copy is tied to a repository by UUID. A UUID uniquely identifies a repository. Your plan is to retire the old repository and create two new repositories, each of which contains a portion of the old repository. Both new repositories will have new UUIDs and users will need to check out new working copies from either of them, and discard their existing working copies of the old repo.

This is what I was afraid of.

I don't mind loosing the ability to switch for the repo that will now
only contain dead projects ; but I do want to keep the ability to
switch with the new one with only the active projects.

According to the svn load man page ; the UUID is kept is the svn
repository you load your file into is empty...

I just checked, and they are identical between the old monolithic repo
and the new one.

Doing svn switch --relocate also worked between the old repo and the new one.

Ultimately, I plan to completely remove the old repo and rename the
new one with the same name. Hoping that for users, that the history
was fully rewritten with empty revisions will be completely

Answering to myself:
I had missed that svndumpfilter can take more than one argument ; so I
can do it all in one go.

Received on 2011-06-24 03:02:18 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.