On 22.09.2011 13:19, Jürgen Schmidt wrote:
On Thu, Sep 22, 2011 at 12:40 AM, Jens-Heiner Rechtien<[email protected]>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
