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

Merging 50+ repositories into one

From: Ross Mark <rossm_at_controllingedge.com.au>
Date: 2004-11-01 01:07:02 CET

When we first started using svn I was too used to CVS so decided that
each of our programs/libraries should have a separate repository. We
make use of a lot of svn:externals references as the programs depend on
each other and it all works pretty well. Except when it comes time to do
a release and we forget to tag all of the projects. We especially have
problems with svn:externals as it doesn't get updated by tags.

We are now considering merging all of the repositories into one so that
tracking versions of software for a release would be a lot simpler. We
know we have to modify the dump files to fix path names to match the new
repository layout but we are wondering what else we should be aware of?

For example will the commit dates/times change when loaded into the new
rep? We make use of the use-commit-times setting for some of the checkouts.

Given a lot of our comments about copys and merges make references to
numeric versions we are considering writing a filter that combine all
rev 1 for each repository and loading them all in one transaction. Then
filter all rev 2 for each repository and loading them together that way
revX of the big repository was the same as revX of the original. The log
messages would have to concatenated together, authors merged into a list
and only one of the date stamps could be used. Apart from those problems
is it a reasonable idea?

Is there anything else that could cause us problems?

Cheers

Ross

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Nov 1 01:07:26 2004

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.