Migration into a different repository

["Oefelein, Martina" <Ma...@dionex.com>]

Hi,
 
We want to move a project that started in a separate repository into our main repository, so that we can more easily share code with other projects in that repository. We are not concerned about loosing history, so a simple import/export should do the job. However, I don't want to interrupt people's workflow, so I'm concerned about local modifications in their working copies at the time of migration, how to transfer these into the new working copy. It seems the best way would be to used patches.
 
So I came up with the following plan:

1.	Announce the migration time at least one day in advance
2.	Developers should try to get their local modifiations commited before the migration starts (in order to avoid step 9) where possible
3.	Notify everyone that the migration is starting
4.	Block write access to the old repository
5.	Export the latest revision to an empty folder
6.	Import that folder into the main repository
7.	Notify everyone that the migration is finished
	
8.	Developers should check out a new working copy from the new location
9.	Anybody who has uncommited local modifiations that he wants to preserve:

	1.	Update the old working copy to HEAD
	2.	Create a patch from the old working copy, including all modifications to be preserved
	3.	Apply the patch to the new working copy
	4.	Commit the changes in the new working copy when they are finished

Am I missing something? Do you think this is a reasonable strategy? We are using TortoiseSVN on Windows.

ciao 
Martina 

Re: Migration into a different repository

[Ryan Schmidt <su...@ryandesign.com>]

On Apr 19, 2007, at 12:14, Oefelein, Martina wrote:

> We want to move a project that started in a separate repository  
> into our main repository, so that we can more easily share code  
> with other projects in that repository. We are not concerned about  
> loosing history, so a simple import/export should do the job.

Note that it is not difficult to preserve the history. You can  
"svnadmin dump" the separate project's repo into a dumpfile, then  
"svnadmin load" it into a particular directory of the main  
repository. All the history will be preserved. Revision numbers will  
be renumbered, however, so if you had log messages which made  
reference to particular revisions in the old repo, those references  
would now be inaccurate.

Note also that simply using "svn export" instead will not only lose  
the history, but will also lose any Subversion properties you may  
have been using -- svn:executable, svn:mime-type, svn:eol-style,  
svn:externals, to name a few. The "svnadmin dump" strategy preserves  
all this. If you want to preserve this but expressly do not want the  
history, then use "svnadmin dump -r HEAD" from the old repo instead  
of "svn export".


> However, I don't want to interrupt people's workflow, so I'm  
> concerned about local modifications in their working copies at the  
> time of migration, how to transfer these into the new working copy.  
> It seems the best way would be to used patches.
>
> So I came up with the following plan:
>
> 1.	Announce the migration time at least one day in advance
> 2.	Developers should try to get their local modifiations commited  
> before the migration starts (in order to avoid step 9) where possible
> 3.	Notify everyone that the migration is starting
> 4.	Block write access to the old repository
> 5.	Export the latest revision to an empty folder
> 6.	Import that folder into the main repository
> 7.	Notify everyone that the migration is finished
> 	
> 8.	Developers should check out a new working copy from the new  
> location
> 9.	Anybody who has uncommited local modifiations that he wants to  
> preserve:
>
> 	1.	Update the old working copy to HEAD

If you want them to be able to do that, that means the old repository  
will still be accessible on the network after the migration  
completes. If you do this, you will want to ensure that nobody can  
commit any changes to the old repo. You could do this by installing a  
pre-commit hook which prints a message informing people to use the  
new repo, then exits with a nonzero status code.

> 	2.	Create a patch from the old working copy, including all  
> modifications to be preserved
> 	3.	Apply the patch to the new working copy
> 	4.	Commit the changes in the new working copy when they are finished
>
> Am I missing something? Do you think this is a reasonable strategy?  
> We are using TortoiseSVN on Windows.

It should work. You should strongly encourage everyone to check in  
their outstanding modifications before the migration takes place. It  
will probably be easier.


-- 

To reply to the mailing list, please use your mailer's Reply To All  
function


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org