On 09/20/2011 05:26 PM, Rob Weir wrote:
Ai2011/9/20 Pavel Janík<[email protected]>:
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
