Mailing-List: contact ooo-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: ooo-dev@incubator.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Message-ID: <4E2AEC98.6010209@apache.org>
Date: Sat, 23 Jul 2011 17:45:28 +0200
From: =?ISO-8859-1?Q?Florent_Andr=E9?= <florent@apache.org>
Reply-To: florent@apache.org
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
 rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11
MIME-Version: 1.0
To: ooo-dev@incubator.apache.org
Subject: Re: single repository status
References: 
 <CABD8fLWAn1afWKDmdD46G302XJhZRjdeao+-OeY4Mca5gEpNNg@mail.gmail.com>
	<ivn40s$gqn$1@dough.gmane.org>	<j04sqo$mj0$1@dough.gmane.org>
	<20110720100513.GB12674@ulungele.erack.de>	<4E2826C7.7060202@web.de>
	<4E2ABD0D.6090408@4sengines.com>
 <CAP-ksoiUHGtOES_oSPPVsLBtGj5VU-Q9F+qhEKpPkMcAHYek-g@mail.gmail.com>
In-Reply-To: 
 <CAP-ksoiUHGtOES_oSPPVsLBtGj5VU-Q9F+qhEKpPkMcAHYek-g@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit


On 07/23/2011 03:46 PM, Rob Weir wrote:
> On Sat, Jul 23, 2011 at 8:22 AM, florent andr�
> <florent.andre-dev@4sengines.com>  wrote:
>> Hi,
>>
>> I also think that we need codebase in svn soon.
>>
>
> Yes.
>
>> Following your all pretty good comments, import a "perfect" hg history into
>> svn seems not to be quite easy... and will require works and effort.
>>
>> As Michael Stahl says "Hg/git/otherDSCMs and SVN have fundamentally
>> different data models for representing branching/merging".
>> So hg -->  svn is complicated but hg -->  git seems to works pretty well.
>>
>> The main point is to have a way to lurk the history, and to host this
>> history into Apache infra in order to be Oracle's server shut down tolerant.
>>
>> So, what about this proposal ? :
>>
>> - ask infra to set up a special git ooo-history
>
> I'm assuming that ooo-history would be read-only?

yep, as all existing git repo.
The only "special" things is that this git repo isn't link with an 
existing svn repos (actual apache git repo are read-only mirror of svn).

>
>> - import only the main hg branch into svn
>> - if someone interested in a specific hg branch :
>> ** git checkout theBranch (from ooo-history)
>> ** svn create branch from trunk ( Btrunk)
>> ** diff Btrunk / theBranch for creating patch
>> ** apply patch on Btrunk
>> ** commit Btrunk
>>
>> Sure we will lost a lot of history in svn... but we still have it in git
>> ooo-history...
>> ... And a new (hi)story begin in Apache svn ! :)
>>
>> This will require infra to set up a special ooo-history git repos... but if
>> we are kind they may accept :).
>>
>> What do you think ?
>>
>
> I like the "lazy" approach.  Defer the branch conversion work until it
> is actually needed.  It puts the human judgement in the loop at the
> time when it is needed.  If we believed that 100% (or even 80% or 90%)
> of the CWS would be needed immediately for integration into our first
> release, then it might make sense to do all that work up front.  But
> if we believe that only a few are needed, then it doesn't make sense
> to hold up the entire project for this.

hg repos seems hudge and if we all import in one shoot there is - IMO - 
a risk of being lost in this ocean of code.

Begin with the more "almost ready" hg branch and then import code after 
human judgement could be a more step by step and manageable processing.

>
> One concern would be on the IP perspective.  Before we can have a
> release or graduate from Podling, we need to review our source code
> and remove all incompatible 3rd party components.  We're also working
> to ensure that the Oracle SGA is updated to contain all the files we
> need for AOOo.  If we have two repositories, a "clean" one in SVN and
> an "unreviewed" version in git that we occasionally dip into for
> unintegrated branches, then IP compliance becomes more difficult.
> Maybe not impossible, but certainly more complicated.

Oracle SGA is for sure a things to fix first.

Considering 2 repositories and release/graduation :
- we have to *check it carefully*, but from my POV the "official" repos 
will be the svn one, ooo-history is just a backup one, so might not be 
considered for release / graduate

- the IP / incompatible 3rd party, could be more easily manageable I 
think because :
* we first working on one hg branch/trunk and not on all the code ocean. 
So it will be more easy to get rid of IP and 3rd because less place to 
get them hidden.
* integration of a new svn branch (from ooo-history) will be a patch to 
the clean svn trunk. This patch / new branch will be first checked by 
the "human behind the commit" and after by others ooo commiters...
Code added will me less, more that double checked, so ip/3rd will have 
less chances to use the black door.

++


>
> -Rob
>
>
>> ++
>>
>>
>> On 07/21/2011 03:16 PM, Jens-Heiner Rechtien wrote:
>>>
>>> On 07/20/2011 12:05 PM, Eike Rathke wrote:
>>>>
>>>> Hi Michael,
>>>>
>>>> On Tuesday, 2011-07-19 23:26:48 +0200, Michael Stahl wrote:
>>>>
>>>>> unfortunately it seems none of the tools that convert from HG or git
>>>>> to SVN can create SVN branches with SVN mergeinfo (necessary in
>>>>> order to be able to merge the branches back into the trunk).
>>>>>
>>>>> there are some tools to convert from git that can create SVN
>>>>> branches, but they leave out the SVN mergeinfo; apparently the
>>>>> intent is to maintain a read-only mirror...
>>>>
>>>> I didn't dug deeper into this, but conversion from hg to git should be
>>>> pretty straight forward and then there's git-svn, would that be viable
>>>> to import branches as well?
>>>>
>>>>
>>>>> basically we have these options for converting to SVN:
>>>>>
>>>>> 1. convert full history
>>>>> requires writing tool to create SVN branches and mergeinfo
>>>>>
>>>>> 2. convert trunk only, using follow-first-parent heuristic
>>>>> with hacks where we want to follow second parent instead
>>>>>
>>>>> 3. no history in SVN, just check in OOO340 tip
>>>>
>>>> I'd prefer #3 and have a read-only hg/git repository for cases where one
>>>> really wants to lookup history. AOOo needs to get its code base going.
>>>
>>> +1 for #3. We need the repository ASAP to get going. If we have to write
>>> the conversion tools first we'll loose way to much time which could be
>>> spent better on getting AOOo 3.4 (or whatever the first AOOo release
>>> will be called) out of the door. A pity that Apache git support is not
>>> ready for prime time ... would make things so much easier.
>>>
>>> Heiner
>>>
>>>
>>