On Thu, Sep 22, 2011 at 12:40 AM, Jens-Heiner Rechtien <jhrecht...@web.de>wrote:
> On 09/20/2011 05:26 PM, Rob Weir wrote: > >> Ai2011/9/20 Pavel Janík<pa...@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
