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

Re: Make a project version already in repo to be after (in revision history) a new added version

From: Ryan Schmidt <subversion-2009a_at_ryandesign.com>
Date: Thu, 8 Jan 2009 20:52:12 -0600

On Jan 7, 2009, at 19:14, Diego Fernández Durán wrote:

> - I've a long term project with 2 key release versions:
> V_1 and V_2.
> - V_1 is not under version control (of any kind).
> - V_2 is imported in version control after 3 months of development
> since V_1, so the initial V_2's version in repo and V_1 differ in
> hundreds of changes.
> - We continue V_2's development using the repository and making
> several revisions.
> Now, we're asked to insert V_1 in the repository as the first
> revision
> and V_2 as the second revision keeping the revision log from the
> current
> repository (newrev = oldrev+1 in this scenario), so the changes
> between
> V_1 and V_2 get inserted in the repository and we can continue
> development knowing where we came from.
> I've searching and I think the solution is:
> 1. Make a dump file of the old repository containing V_2.
> 2. Create new repository.
> 3. Import V_1 as first revision of new repository.
> 4. Do 'svnadmin load olddump' in the new repository where
> "olddump" is
> the old repository's dump.
> Is this the right solution? Can anybody point me in the right
> direction?

I don't think it will be possible to insert V_1 into the repository
now AND have V_2 think it descended from V_1. You can certainly
import V_1 now into a separate branch, but it will be totally
disconnected from and not share any history with V_2.

If you were doing this at the very beginning of the project, it would
have been possible. If you had two directories on disk, one with V_1
and one with V_2, you would "svn import" V_1 into the new
repository's trunk, then "svn copy" that to make a V_1 branch, then
use "svn_load_dirs.pl" to import V_2 on top of the V_1 that's in
trunk. Then continue developing V_2 in the trunk and V_1 on the
branch. This type of import uses the "vendor branch" strategy
described in the book:


On second thought, it *might* be possible to do now after the fact.
Let me see...

In your current repository, "svn export" the first revision of V_2
that existed in your repository. For example if that was revision 5
(assuming it took a few revisions to set up some directories initially):

svn export url://to/V_2_repo -r 5 V_2_r5_export

Now "svnadmin dump" everything else:

svnadmin dump -r6:HEAD /path/to/V_2_repo V_2_r6-HEAD_dump

Now "svnadmin create" a new repo:

svnadmin create /path/to/new_repo

Now create in that repository the same structure you had in the V_2
repository, possibly just trunk, branches, tags:

svn mkdir url://to/new_repo/{trunk,branches,tags}

"svn import" the V_1 code where you want it, e.g. into the trunk:

svn import /path/to/V_1_code url://to/new_repo/trunk

"svn copy" the trunk to a V_1 branch:

svn copy url://to/new_repo/{trunk,branches/V_1}

Load the V_2_r5_export on top of the trunk with "svn_load_dirs.pl":

svn_load_dirs.pl svn_load_dirs.pl url://to/new_repo trunk V_2_r5_export

Use "svnadmin load" to bring in the rest of the history of V_2:

svnadmin load /path/to/new_repo < V_2_r6-HEAD_dump

Like I said, that *might* work. I haven't tried it; this is just off
the top of my head.

Note that revision numbers in your new repository will likely not
match those in your old repository, so if you have any commit
messages that refer to previous revision numbers, they'll now be
inaccurate. If you have revision numbers mentioned anywhere in your
issue tracker or other systems, they'll be inaccurate. If you have
any working copies of the old repository, you'll need to throw them
away and check out new working copies from the new repository. It's a
bit of an inconvenience. But if you really want the old history
there, this could be a way to do it.

Or it might be sufficient to just "svn import" the V_1 code into a
new branch and let it be disconnected from anything. That way at
least the V_1 code can be looked at if needed, even if it isn't
connected to V_2's history.


To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-01-09 14:25:21 CET

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.