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

Re: Move to a new repo and keep the history, Part 2

From: Thomas Harold <thomas-lists_at_nybeta.com>
Date: Thu, 14 Jul 2011 14:33:29 -0400

On 7/14/2011 12:29 PM, K F wrote:
> Recap – I would like to move some directories from one repository to
> another while keeping the history.

I went through this a few months ago (and maybe this will help). We
were using a big monolithic repository for all of our jobs. Our
repository was arranged as:

("jobs" repository)

We wanted to split each client out to a different repository. The
output repositories would look like:






Which made all the URLs a lot shorter because the "/A/ABClient" was
often something lengthy like "/A/AB_Acme_Border_Wings_Inc".

1) A shell script to split out a specific directory. We had to edit the
CLCODE and CLPATH lines for each run (took 30-40 minutes to parse the
monolithic jobs repository and split out a particular client's tree).

Each time I did a new client, I had to make sure that everyone was ready
for that client's project tree to move. Alternately, I could have made
the entire "jobs" tree read-only for a week...

(Apologies if there are errors in this as I had to quickly edit out some
client/company specific paths. I always executed the script as "bash -x
scriptname" so I could spot errors. The "date" lines are just there so
I could keep track of how long it took.)




SDFOPTS='--drop-empty-revs --renumber-revs'



svnadmin dump --quiet /var/svn/jobs | \
     svndumpfilter include --quiet $SDFOPTS $CLPATH | gzip > \


2) Created the new repository (such as "jobs-bq" for the BQClient).
Although you could probably roll that into the import script.

# svnadmin create jobs-bq

3) Edited the following import script for each new run. Loading it up
was a fairly quick process. Note that we update the UUID of the new
repository to make sure that nobody commits outdated stuff.

I gave up on trying to re-base on the fly using "sed" and simply moved
all of the individual job folders into the root of the new repository
and then cleaned up the left-over folder.

Our script also had to create the "letter" level in the new repository.
  Otherwise the import had no place to hang itself off of.

You may want to drop the chmod/chgrp lines towards the end. For our
server, we only use svn+ssh authentication. Each users has their own
local account on the server and they belong to a "svn-jobs" group which
gives them read/write access to the entire repository.






svn mkdir -m "Import from jobs" \

gunzip -c ${SRCDIR}${SRCPFX}${CLCODE}${SRCSFX} | \
     svnadmin load --quiet /var/svn/jobs-${CLCODE}

svnlook uuid /var/svn/jobs-${CLCODE}
svnadmin setuuid /var/svn/jobs-${CLCODE}
svnlook uuid /var/svn/jobs-${CLCODE}
svnadmin pack /var/svn/jobs-${CLCODE}

chmod -R 775 /var/svn/jobs-${CLCODE}
chmod -R g+s /var/svn/jobs-${CLCODE}/db
chgrp -R svn-jobs /var/svn/jobs-${CLCODE}


4) After the load into the new repository, I would access the repository
through TortoiseSVN's Repository Browser and drag all of the individual
jobs folders from being under "/A/ABClient/" up to the root of the new
repository. Then I deleted the "/A/ABClient/" tree.

If I could have figured out how to remap on the fly via "sed", I could
have avoided step #4. But it was good enough for our purposes and a few
historical entries in the SVN log showing the movement of the folders
wasn't a big deal.

5) After we finished the splits, we chmod'd the old repository to be
read-only and took it completely offline a month or two later.
Received on 2011-07-14 20:34:23 CEST

This is an archived mail posted to the Subversion Users mailing list.