From ooo-dev-return-209-apmail-incubator-ooo-dev-archive=incubator.apache.org@incubator.apache.org Wed Jun 15 10:43:34 2011 Return-Path: X-Original-To: apmail-incubator-ooo-dev-archive@minotaur.apache.org Delivered-To: apmail-incubator-ooo-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 97D7041E0 for ; Wed, 15 Jun 2011 10:43:34 +0000 (UTC) Received: (qmail 89484 invoked by uid 500); 15 Jun 2011 10:43:34 -0000 Delivered-To: apmail-incubator-ooo-dev-archive@incubator.apache.org Received: (qmail 89410 invoked by uid 500); 15 Jun 2011 10:43:34 -0000 Mailing-List: contact ooo-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: ooo-dev@incubator.apache.org Delivered-To: mailing list ooo-dev@incubator.apache.org Received: (qmail 89402 invoked by uid 99); 15 Jun 2011 10:43:34 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 15 Jun 2011 10:43:34 +0000 X-ASF-Spam-Status: No, hits=0.0 required=5.0 tests=FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: local policy) Received: from [217.72.192.234] (HELO fmmailgate03.web.de) (217.72.192.234) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 15 Jun 2011 10:43:29 +0000 Received: from smtp08.web.de ( [172.20.5.216]) by fmmailgate03.web.de (Postfix) with ESMTP id D643519248BF9 for ; Wed, 15 Jun 2011 12:42:53 +0200 (CEST) Received: from [213.39.169.237] (helo=[192.168.2.192]) by smtp08.web.de with asmtp (TLSv1:AES256-SHA:256) (WEB.DE 4.110 #2) id 1QWnYj-0002Xo-00 for ooo-dev@incubator.apache.org; Wed, 15 Jun 2011 12:42:53 +0200 Message-ID: <4DF88CAC.2080801@web.de> Date: Wed, 15 Jun 2011 12:42:52 +0200 From: Jens-Heiner Rechtien User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110516 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: ooo-dev@incubator.apache.org Subject: Re: Repository arrangement (was: [discuss] remove of binfilter module) References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: jhrechtien@web.de X-Sender: jhrechtien@web.de X-Provags-ID: V01U2FsdGVkX1/IjaEoAWnxGfYmU3JkZJ1ZIeMWP4H0p1EI2QGV cy9xutC67iVUZUUkoe7llLmf/wy5dq5E/bIjf/h39qf4JWZ3me G0lccNsJk= On 06/15/2011 10:48 AM, Greg Stein wrote: > On Wed, Jun 15, 2011 at 03:51, Christian Lippka 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