incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jens-Heiner Rechtien <jhrecht...@web.de>
Subject Re: handling of ext_sources - Juergen's suggestion [was: Re: A systematic approach to IP review?]
Date Wed, 21 Sep 2011 22:40:02 GMT
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.

Heiner

-- 
Jens-Heiner Rechtien

Mime
View raw message