openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pedro Giffuni <>
Subject Re: ooo large commit breaks mirror sync !!
Date Wed, 22 Feb 2012 02:53:29 GMT
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-
>>>   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
> 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

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=""/>
> ...
>      <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/ .



View raw message