openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Florent André <>
Subject Re: single repository status
Date Sat, 23 Jul 2011 15:45:28 GMT

On 07/23/2011 03:46 PM, Rob Weir wrote:
> On Sat, Jul 23, 2011 at 8:22 AM, florent andré
> <>  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

View raw message