On 06/15/2011 10:48 AM, Greg Stein wrote:
On Wed, Jun 15, 2011 at 03:51, Christian Lippka<[email protected]> 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
