On 20.09.2011 16:36, Pavel Janík wrote:
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.
What might be the best way to handle 3rd party code in AOOo probably
will depend on the needs of the developers as well as on legal requirements.
We had these tarballs plus patches IIRC because Sun Legal required that
all used 3rd party stuff should be preserved in our repos in its
original form.
As a developer I always had preferred to have 3rd party code treated in
the *build* like the internal source code.
So if there wasn't a requirement to have unpatched sources in the
repository, the most natural way to keep 3rd party stuff would be to
have a third sub-repo "3rdparty" next to "main" and "extras" with the
3rd party stuff checked in. Not the tarballs, just the unpacked content.
I wouldn't give up the patches, as they allow to handle updates better.
This would cause a problem, as direct changes to the 3rd party stuff
without additional authorization (means: changing the source code must
not happen accidently, only when the 3rd party code gets an update from
upstream) must be prevented, while still patch files must be allowed to
added, removed, or changed, not the original source code. If that wasn't
possible or too cumbersome, checking in the tarballs in "3rdparty" would
be better.
As svn users never download the complete history as DSCM users do, the
pain of binary files in the repo isn't that hard. In case AOOo moved to
a DSCM again later, the tarballs could be moved out again easily.
Regards,
Mathias
