incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jens-Heiner Rechtien <jhrecht...@web.de>
Subject Re: Repository arrangement (was: [discuss] remove of binfilter module)
Date Wed, 15 Jun 2011 10:42:52 GMT
On 06/15/2011 10:48 AM, Greg Stein wrote:
> On Wed, Jun 15, 2011 at 03:51, Christian Lippka<cl@lippka.com>  wrote:
>> ...
>> I do not know if apache allows to have multiple svn repositories for each
>> project.
>> But moving binfilter to a separate repository and refactor it to become a
>> build independent filter makes sense. Since it does not alter any core
>> internal
>> stuff, it is also something that one or more developers can work on without
>> interfering with ongoing core development.
>
> All projects at the ASF live in one single repository:
>    http://svn.apache.org/repos/asf/
>
> Thus, there is no notion of "multiple" repositories or "separate"
> repositories. The question revolves around organization of our area of
> the repository.
>
> Let's consider that we have some $PREFIX based on the above (e.g.
> .../repos/asf/ooo/). We could then organize along standard Subversion
> patterns:
>
> PREFIX/
>    trunk/
>    tags/
>    branches/
>
> The above pattern works great for a single set of deliverables,
> released in unison, on the same release pattern. It sounds like OOo is
> going to want more than one release vehicle. That gets really hard on
> the community, compared to releasing 50 components at once, even if 40
> are unchanged. But for conversation, let's say we want to enable
> separate delivery schedules for the core applications, the extensions,
> and the language packs. In this scenario, we might have:
>
> PREFIX/
>    app/
>      trunk/
>      tags/
>      branches/
>    languages/
>      en/
>        trunk/
>        tags/
>        branches/
>      pt/
>      ...
>    extensions/
>      ext1/
>        trunk/
>        tags/
>        branches/
>      ext2/
>      ...
>
> The options are quite open. The choice is primarily driven by release
> schedules of components, and their inter-dependencies.
>
> Subversion is also very easy to re-arrange. We can decide one thing,
> and change it two years from now.
>
> The decision point is how to break up (OR NOT!!) the release artifacts
> into groups.

For binfilter alone creating a complicate repository structure like in 
your second example wouldn't make sense. It's either removing it 
completely or keeping it and release it together with the rest of the 
stuff. After all it has dependencies into the core, they just don't 
change very often. I think Christian is more concerned about the 
handling cost of binfilter in day-to-day development work in the OOo 
applications. It needs a) to be checked out using additional disk space 
and b) needs to be compiled, packaged etc.

For a) we are talking about 52MB or so of easily compressible stuff 
which isn't that much compared to the rest (1.1 GB + 0.5 GB languages). 
Of course, SVN doubles the disk space requirement, but still. Point b) 
building time can be saved by configuring building binfilter away for 
all developers who aren't interested in it.

Additional languages (other than en-US) are a different story, as they 
are some really large blobs on the disk and they can be handled 
separately from the rest. We keep them already in a second mercurial 
repository. Not sure if we want to release them separately, though.

Extensions on the other hand might be on a truly different release 
schedule, but at least the "bundled" extensions will be released 
together with OOo

I would suggest that we go with the standard SVN repository structure as 
in your example 1.

PREFIX/
    trunk/
        app
        languages (other than en-US)
        bundled_extensions
    tags/
        app
        languages (other than en-US)
        bundled_extensions
    branches/
        app
        languages (other than en-US)
        bundled_extensions

This way someone can check out PREFIX/trunk/app and build a working OOo 
without additional languages and save some time.

Heiner

-- 
Jens-Heiner Rechtien

Mime
View raw message