Mailing-List: contact ooo-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: ooo-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of Mathias_Bauer@gmx.net
 designates 213.165.64.23 as permitted sender)
Message-ID: <4E0AFE6E.9070702@gmx.net>
Date: Wed, 29 Jun 2011 12:29:02 +0200
From: Mathias Bauer <Mathias_Bauer@gmx.net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US;
 rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Mnenhy/0.8.3
 OracleBeehiveExtension/1.0.0.2-OracleInternal
 ObetStats/CATCATCATCATCATCAFCATLAF_1292428138647-396660266 Thunderbird/3.1.11
MIME-Version: 1.0
To: ooo-dev@incubator.apache.org
Subject: Re: Building a single Hg repository
References: <BANLkTinN1ee-dTM1kLQ_ugZmbukB__DXkg@mail.gmail.com>
In-Reply-To: <BANLkTinN1ee-dTM1kLQ_ugZmbukB__DXkg@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 29.06.2011 05:27, Greg Stein wrote:
> On Mon, Jun 27, 2011 at 05:42, Jens-Heiner Rechtien<jhrechtien@web.de>  wrote:
>> On 06/27/2011 01:08 AM, Greg Stein wrote:
>> ...
>>>> Merging them in hg is easy, just pull/merge. But ... we are talking about
>>>> a
>>>> hundred or so CWSs here. In all kinds of readiness states.
>>>> http://hg.services.openoffice.org
>>>>
>>>> If we merge them now, we won't have a working OOo for a long time. Now,
>>>> we
>>>> could skip the merge part and leave the heads "dangling". Hg heads are
>>>> kinda
>>>
>>> That's what I was thinking. And then map these "dangling" heads to
>>> individual branches in svn.
>>>
>>>> anonymous branches in Mercurial. Don't know if a repository with multiple
>>>> heads can be converted to SVN. Probably quite tricky (the tool would need
>>>> to
>>>> generate sensible names for the different heads).
>>>
>>> If the converter tool doesn't have the feature, it seems pretty
>>> straight-forward to add code to either provide a name mapping for
>>> them, or auto-generate names.
>>
>> The anonymous heads could be marked with the cws name as a mercurial
>> bookmark, just after the individual pull step. That way the information is
>> at least already in the all-in-one hg repository. A smart converter could
>> use them to generate svn branch names. Something along this lines:
>>
>> $ cd<all-in-one-respository>
>> $ hg pull ../cws/os151
>>
>> ... the latest changeset of CWS os151 is now tip
>>
>> $ hg bookmark -r tip os151
>>
>> $ hg bookmarks
>>    os151                     276718:f4d674e63830
>>    ....
>
> Great. Thanks for the pointers.
>
> I'm going to start updating the single-hg.sh (see tools/dev/) with
> this stuff. I'd appreciate if you could keep an eye on the commits and
> correct me where I stray. I've never used Mercurial before.
>
> I've read up on the difference between: tags, branches, local tags,
> and bookmarks. I agree that it seems bookmarks are appropriate for
> this purpose. We could technically use a tag since no further work
> would be done in this "single" repository. However, we may be able to
> use the bookmarks as an indicator for branch construction (vs a static
> copy in tags/).
>
> I suspect that a lot of work will happen on the Convert extension to
> Mercurial to manage this transition :-)
>
> One more thing... I cloned one of the CWSs (ab78), and it was 2.8 Gb.
> My clone of DEV300 is 3.5 Gb. Is the size of that CWS typical? There
> are about 250 CWSs hosted at OOo. If the average holds, I would need
> to clone 700 Gb of material down to my system to perform the
> integration.
>
> Am I missing something? Is there a better way? etc.

As your local hg repo is just an intermediate step from where you export 
to svn, you could pull all cws into one repository. The majority of the 
different repositories (master or cws) consists of almost the same 
changesets, so pulling into one repo will save a lot of disk space.

This has been tried by several people and it worked for them.

Someone has created a Mercurial extension that makes this process pretty 
easy:

http://mercurial.selenic.com/wiki/BranchmirrorExtension

As some of our cws are based on the DEV300 repo and some are based on 
the OOo340 repo, you will need two repos or someone needs to copy the 
cws from dev300 to ooo340 before.

Regards,
Mathias