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

Re: Move several repositories into on but keeping the history?

From: Nico Kadel-Garcia <nkadel_at_gmail.com>
Date: Mon, 10 Aug 2009 08:37:11 -0400

On Sun, Aug 9, 2009 at 8:08 PM, Ryan
Schmidt<subversion-2009b_at_ryandesign.com> wrote:
>
> On Aug 9, 2009, at 18:11, Nico Kadel-Garcia wrote:
>
>> On Sun, Aug 9, 2009 at 4:56 AM, Stephen Connolly wrote:
>>
>>> 2009/8/7 Ryan Schmidt wrote:
>>>
>>>> On Aug 7, 2009, at 10:25, Steve Constable wrote:
>>>>
>>>>> I'd like to consolidate several repositories into one large one.
>>>>> What I'm worried about is that I might loose all the history from
>>>>> each of the repos.
>>>>> Is there a way to keep the history? I'm imagining that the old
>>>>> repository numbers would get renumbered...but that I can live with
>>>>> since that would be unavoidable.
>>>>
>>>> Of course you can keep the history. :)
>>>>
>>>> 1. "svnadmin dump" each old repository to a file.
>>>>
>>>> 2. "svnadmin create" the new repository.
>>
>> Which provides a temporally out-of-order changelist.
>
> Only if you use the "3a" method I described. The "3b" method will result in
> the revisions being in chronological order.
>
>> This is _begging_
>> for arbitrary pain, especially if any components happen to come from
>> the same relative locations. You know, like "[repourl]/trunk", which
>> is the standard location for an independent repository's main
>> codeline? Unweaving that into different locations is simply begging
>> for pain.
>
> I don't think I understand the point you're trying to make here. I had
> assumed there was a [repourl]/trunk (and [repourl]/branches and
> [repourl]/tags) in each of the projects' old repositories, and that these
> would now be moved into a single combined repository with the structure
> [repourl]/[project]/{trunk,tags,branches}.

You're making a reasonable assumption. I recommend against making such
reasonable assumptions when people ask such questions, because our
original poster did not say.

For example, our poster could have [repo1]/{trunk,branches,tags} and
[repo2]/{trunk,branches,tags}, and desire to merge them into
[newrepo]/trunk/[project1], [newrepo]/trunk/{project2}, and the
wonderfully interwoven potential nightmare of [newrepo]/branches/{some
from repo1, some from repo2, with unpredictable and potentially
overlapping directory names}.

Sadly, I've had to deal with that sort of desired merging: it's not
unheard of when projects get merged to want to distill them into a
new, common "trunk". And resolving overlaps can get..... messy.

>> The simple answer is "don't". Make a clean break: Lock down the old
>> repositories, do an "svn export" to a new trunk, and have the first
>> commit include a pointer to the old repository.
>
> That would be another option, but I wouldn't really recommend that, since I
> don't quite see what problems you're envisioning.
>
>

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2382048

To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-08-10 14:38:17 CEST

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.