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
Received on Fri Apr 20 00:35:03 2007