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 dennis.hamilton@acm.org
 designates 75.98.160.130 as permitted sender)
Reply-To: <dennis.hamilton@acm.org>
From: "Dennis E. Hamilton" <dennis.hamilton@acm.org>
To: <ooo-dev@incubator.apache.org>
References: <1312855540.31694.YahooMailClassic@web113519.mail.gq1.yahoo.com>
 <4E426F67.5050802@gmx.net> <4E4274C4.30007@wtnet.de>
In-Reply-To: <4E4274C4.30007@wtnet.de>
Subject: RE: [Repo] SVN ETA? (was Re: Request for comments: Community Wiki
 Services web page.)
Date: Wed, 10 Aug 2011 07:37:26 -0700
Organization: NuovoDoc
Message-ID: <008f01cc576b$06b56490$14202db0$@acm.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Thread-Index: AQEjveE/ricUPCOpKbcJ3I9LUc1PAAKEIA0IAamm/f6WRelBkA==
Content-Language: en-us

I believe one speed-bump that has been raised is the maximum storage =
available to an Apache Extra.  I'm not sure anyone has taken an action =
to find out if we can have an exception from Google Code.  (The Terms of =
Use don't specify a maximum, so I don't know where that came from.)

It does look like consensus is to do the division between SVN and Hg in =
this manner though.

 - Dennis

-----Original Message-----
From: Marcus (OOo) [mailto:marcus.mail@wtnet.de]=20
Sent: Wednesday, August 10, 2011 05:09
To: ooo-dev@incubator.apache.org
Subject: Re: [Repo] SVN ETA? (was Re: Request for comments: Community =
Wiki Services web page.)

Am 08/10/2011 01:45 PM, schrieb Mathias Bauer:
> On 09.08.2011 04:05, Pedro F. Giffuni wrote:
>
>> Hi;
>>
>> I appreciate the tough work that is being done to transfer
>> the Wiki, forums, etc ... but I would've thought the greatest
>> priority was the SVN repository.
>>
>> Any reassuring comment on this? Something like "we are
>> working on this but the script will still require a month to
>> complete the conversion" is better than no news at all.
>
> Let me try to recap the consensus so far. I was on vaction for two
> weeks, so I was not involved in all discussions.
>
> A full conversion hg ->  svn for the trunk repo and all cws is =
considered
> to be impossible, so all conversions will happen on the trunk repo =
only.
>
> It was mentioned that preserving history looks hard, so most of us
> agreed to move over the tip from the trunk repo into svn only, without
> history.

I had the impression that we agreed on

a) moving the OOO340m1 tip into ASF SVN and to loose history, so that we =

can start with further improvements very fast and

b) to keep the complete OOo HG repo in apache-extras to keep the CWS=20
developments but also to keep the repo history for reference.

So, at the end there is indeed a way to keep every data + history but=20
also to start with new developments in ASF SVN.

Marcus

> Then Christian Lohmaier tried to use hg convert to convert the whole
> trunk repo and for me it seemed that this was quite promising,
> especially as it seemed that the process could be accelerated by
> importing the very old stuff from the still existing OOo svn repo. Did
> someone give that a try and should we do it?
>
> In case we decided not to try that, is someone already working on
> importing the OOO340m1 repo tip?
>
> We agreed that for the time being we will move all cws into one hg =
repo
> based on the trunk repo, either as branches or as bookmarks (IIRC it =
was
> the latter we agreed on). This combined repo should be transferred to
> apache-extras and hosted there for further treatment.
>
> Sooner or later each cws will be either integrated into the main code
> line of it will be discarded in case we don't consider it worth an
> integration. I maintain my proposal to treat each cws in the following =
way:
>
> - review its content
> - rebase it to the tip of the trunk repo (OOO340m1)
> - create a list of change sets that are not in OOO340m1
> - convert each changeset into a patch
> - create an svn branch from the svn tag corresponding to OOO340m1
> - apply all patches one after another
> - merge with svn tip
>
> In case the cws contains merge commits, we can avoid them by =
re-applying
> all other patches to a OOO340m1 code line, adjusting the code in case
> the patch does not apply correctly and create new patches (very much =
the
> same way as you would do with mq-patches). But of course we could also
> investigate other ways to edit the hg history so that it won't contain
> merge change sets at the end.
>
> As each cws will need a review and some more testing anyway, the
> suggested patch treatment shouldn't create too much additional effort,
> except in pathologic cases.
>
> Regards,
> Mathias