openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jürgen Schmidt <>
Subject Re: handling of ext_sources - Juergen's suggestion [was: Re: A systematic approach to IP review?]
Date Thu, 22 Sep 2011 11:19:05 GMT
On Thu, Sep 22, 2011 at 12:40 AM, Jens-Heiner Rechtien <>wrote:

> On 09/20/2011 05:26 PM, Rob Weir wrote:
>> Ai2011/9/20 Pavel Janík<>:
>>> Have we ever considered using version control to...uh...manage file
>>>> versions?
>>>> Just an idea.
>>> Maybe Heiner will say more, but in the past, we have had the external
>>> tarballs in the VCS, but then we moved them out and it worked very well.
>>> There never was a reason to track external.tar.gz files in VCS, because we
>>> do not change them.
>>> --
>> That's fine.  If they don't change, then doing a "svn update" will not
>> bring them down each time.
>> Aside from being useful for version control, SVN is useful also very
>> useful as an audit trail.  So in the rare occasions when one of these
>> files does change, we know who changed it and why.  This is important
>> for ensuring the IP cleanliness of the project.
>> Is your main concern performance?  Even as individual tarballs,
>> ext-sources is 86 files, 250MB.  ooo/extras is 243 files and 822 MB.
>> And ooo/main is 76,295 files for over 900MB.  So ext-sources is not a
>> huge contributor to download time.
> Placing all the external tarballs in the VCS is a real killer if using a
> distributed SCM like git or Mercurial, thats why we had moved them out. As
> Pavel said, it worked quite nice. As for the audit possibility, we
> referenced the external tar balls in the source tree by file name and a md5
> check sum, which works just as reliantly as putting them directly into the
> repository.
> Nowadays the DSCM have some alternative methods which deal with such blobs
> but in essence they also keep them separate.
> If AOOo ever plans to go back to a DSCM I would keep the source tree and
> the external blobs strictly separated.
> All in all the general SCM tooling community opinion trend seems to be that
> a S(ource)CM system is for, well, source and external dependencies are
> better handled with other mechanism, like Maven or so.
> With SVN all this is less of a concern, naturally.
> ok, we have several arguments for and against but no decision how we want
to move forward. Let us take again a look on it

1. we have a working mechanism to get the externals from somewhere, check
md5 sum, unpack, patch, build
1.1 "somewhere" is configurable during the configure step, initially the
externals are downloaded from

2. having the externals in the repository (SVN) won't be a big issue because
in case of a checkout always the tip version is downloaded
2.1 the SCM can be used to track the used version of the externals for a
specific OO version -> simply checkout the version tag and everything is in
place ...

3. in a DSCM it would be a real problem over time because of the increasing
space of all versions

4. we need a replacement asap
(who knows how long the server will be available)

5. many developers probably work with a local clone of the repository using
for example git svn or something else -> disadvantage of the increasing
space but probably acceptable if a clean local trunk will be kept and

Proposed way to move forward

1. put the externals under .../trunk/ext_sources
2. adapt configure to use this as default, disable the download (maybe
reactivate it later if we move to a DSCM)
3. keep the process with checking the md5 sum as it is (for potential later

Any opinions or suggestions?


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message