incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Armin Le Grand <Armin.Le.Gr...@me.com>
Subject Re: handling of ext_sources - Juergen's suggestion [was: Re: A systematic approach to IP review?]
Date Thu, 22 Sep 2011 11:52:01 GMT
On 22.09.2011 13:19, J├╝rgen Schmidt wrote:
> 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:
...
>>
>> 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?

+1

Best current solution: Added to SVN where it does not really matter, and 
a way to get back when we may change to a DSCM in the future.

> Juergen
>

sincerely,
	Armin
--
ALG


Mime
View raw message