Mailing-List: contact ooo-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: ooo-dev@incubator.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
Message-ID: <4F4458A9.9030801@apache.org>
Date: Tue, 21 Feb 2012 21:53:29 -0500
From: Pedro Giffuni <pfg@apache.org>
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64;
 rv:10.0) Gecko/20120209 Thunderbird/10.0
MIME-Version: 1.0
To: ooo-dev@incubator.apache.org
Subject: Re: ooo large commit breaks mirror sync !!
References: <04a501ccf026$6abf30c0$403d9240$@16degrees.com.au>
 <jhvu5e$ns6$1@dough.gmane.org>
 <89F52680-967C-4D87-89A8-F271A7AC1936@comcast.net>
 <4F4405BC.9030901@apache.org>
 <CD3817A7-A45D-4C89-905C-0D275FB1F6B4@comcast.net>
In-Reply-To: <CD3817A7-A45D-4C89-905C-0D275FB1F6B4@comcast.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 02/21/12 19:08, Dave Fisher wrote:
> On Feb 21, 2012, at 12:59 PM, Pedro Giffuni wrote:
>
>> On 02/21/12 12:46, Dave Fisher wrote:
>>> Hi Armin,
>>>
>>>   U   branches/alg/install/ext_sources/48470d662650c3c074e1c3fabbc67bbd-README_source-9.0.0.7-bj.txt
>>>   U   branches/alg/install/ext_sources/3b179ed18f65c43141528aa6d2440db4-serf-1.0.0.tar.bz2
>>>   U   branches/alg/install/ext_sources/2c9b0f83ed5890af02c0df1c1776f39b-commons-httpclient-3.1-src.tar.gz
>>>   U   branches/alg/install/ext_sources/48a9f787f43a09c0a9b7b00cd1fddbbf-hyphen-2.7.1.tar.gz
>>>   U   branches/alg/install/ext_sources/bc702168a2af16869201dbe91e46ae48-LICENSE_Python-2.6.1
>>> ...
>>> <snipping a bunch of redundant external source tarballs.>
>>> ...
>>>   U   branches/alg/install/ext_sources/c441926f3a552ed3e5b274b62e86af16-STLport-4.0.tar.gz
>>>
>>> Is it necessary to have all these external source tarballs in the branch? These files are kept outside of trunk for a reason - to avoid sledgehammers on changes.
>> I have always been of the idea of keeping them outside the repository.
> They're OK where they are right now. I just think they need to be on a branch. The proper action in svn is to tag.

The recent issue in SVN was due to incorrect properties when uploading 
the initial image of the repository: I don't see how tagging could have 
prevented it but thankfully I don't think changing the properties will 
be necessary in the future.

>> I think that sourceforge will provide some extra space in the extensions
>> site where we could keep them... but it's just an idea for later.
> To me, dealing with the build dependencies is a post-release and pre-graduation issue. SourceForge might be the place if we need a forked version of a tool, but I really think that we should be using the dependent project's distribution as much as we can. For example Apache Tomcat 5.5.35 will always be available from http://archive.apache.org/dist/tomcat/tomcat-5/v5.5.35/
>
> I'm certain that Rob will come up with the case of an orphaned project or one where needed alterations are not taken by the upstream. These are the SourceForge or new Incubator project cases.

The versions of icc and saxon that we carry are obsolete and are not 
available anywhere but it's just a matter of updating them. I don't 
think we carry orphaned projects proper.


> In Apache POI we pull dependencies in an ant build script from maven.
>
>      <property name="repository.m2" value="http://repo1.maven.org"/>
> ...
>      <property name="ooxml.jsr173.jar" location="${ooxml.lib}/stax-api-1.0.1.jar"/>
>      <property name="ooxml.jsr173.url" value="${repository.m2}/maven2/stax/stax-api/1.0.1/stax-api-1.0.1.jar"/>
> ...
>          <antcall target="downloadfile">
>              <param name="sourcefile" value="${ooxml.jsr173.url}"/>
>              <param name="destfile" value="${ooxml.jsr173.jar}"/>
>          </antcall>
> ...
>
> I'm just saying that much can be managed outside of the Apache ooo repository. The best place is somewhere the dependent project has placed their releases.

Yes, that's essentially what FreeBSD ports and all the subsequent linux
reinventions (Debian, Gentoo, etc)  do. Subversion is not
a good place for holding them though.

> For cases of files like the Adobe core AFMs - Adobe-Core35_AFMs-314.tar.gz These don't need to be external they are category A[1] and can be in the source tree if that makes sense:

For an alternative approach look at the instructions in 
main/stax/download/ .

cheers,

Pedro.