You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openoffice.apache.org by Greg Stein <gs...@gmail.com> on 2011/06/15 10:48:53 UTC
Repository arrangement (was: [discuss] remove of binfilter module)
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.
Cheers,
-g
Re: Repository arrangement (was: [discuss] remove of binfilter module)
Posted by Jens-Heiner Rechtien <jh...@web.de>.
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
RE: Repository arrangement (was: [discuss] remove of binfilter module)
Posted by "Dennis E. Hamilton" <de...@acm.org>.
+1 Essatamundo
-----Original Message-----
From: Greg Stein [mailto:gstein@gmail.com]
Sent: Wednesday, June 15, 2011 01:49
To: ooo-dev@incubator.apache.org
Subject: Repository arrangement (was: [discuss] remove of binfilter module)
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.
Cheers,
-g
Re: Repository arrangement (was: [discuss] remove of binfilter module)
Posted by Mathias Bauer <Ma...@gmx.net>.
Hi Greg,
On 15.06.2011 10:48, 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.
So then let's just express it differently:
We can have several "sub repositories" (in reality just sub folders of
/repos/asf/ooo) that can be checked out separately. That's an option
that you forget easily when you are used to DSCM.
In our own interest we should avoid having changesets that cross the
boundaries of these sub folders. This would create problems in case we
wanted to move to separate git repos in the future or allow to maintain
bridges or conversions to separate git repos.
Regards,
Mathias