incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Weir <>
Subject Re: [Repo] SVN ETA? (was Re: Request for comments: Community Wiki Services web page.)
Date Wed, 10 Aug 2011 14:18:56 GMT
On Wed, Aug 10, 2011 at 8:08 AM, Marcus (OOo) <> wrote:
> 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
> 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 also
> to start with new developments in ASF SVN.

That is the outline of what I understood as well.  I think we just
need to write up the plan in some more detail, post it to the list (or
a link to a proposal on the wiki) in a [PROPOSAL] thread and state
that we're assuming lazy consensus, and we'll go ahead if there are no
objections in 3 days.

The additional details would deal with things like:

1) In SVN, since we have single repository, how specifically are we
handling the core versus the languages?  I thought the proposal was to
put them in separate directories within the same repo.  But we should
be explicit.

2) We want to avoid sending out gigabytes of commit notifications when
we check in the tip.  So the plan should include how we're going to
avoid that.  One idea would be to make a local working copy, commit
that to a local SVN, get a svnadmin dump of that repository, stick it
on the web someplace where Apache Infra can get to it, then open a
JIRA ticket for them to import the dump.

3) The legacy history should be easier, since that is Hg -->Hg on Apache-extras.

4) We need names of volunteers for each of the above tasks

> 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

View raw message