incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jürgen Schmidt <jogischm...@googlemail.com>
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 <jhrechtien@web.de>wrote:

> On 09/20/2011 05:26 PM, Rob Weir wrote:
>
>> Ai2011/9/20 Pavel Janík<Pavel@janik.cz>:
>>
>>> 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 http://hg.services.openoffice.org/binaries

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 http://hg.services.openoffice.org/binaries 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
updated

Proposed way to move forward

1. put the externals under .../trunk/ext_sources
.../trunk/ext_sources
.../trunk/main
.../trunk/extras
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
use)

Any opinions or suggestions?

Juergen

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