FWIW; I don't like the patches because I can't really examine well the code, besides this is something the VCS handles acceptably: commit the original sourcecode and then apply the patches in a different commit. If we start with up to date versions there would not be much trouble.
just my $0.02, not an objection. Pedro. --- On Wed, 9/28/11, Jürgen Schmidt <jogischm...@googlemail.com> wrote: ... > > 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. > > > > i also wouldn't give up the patches and for that reason i > would like to move > forward for now with keeping the tarballs as proposed. But > i like the name > "3rdparty" for the directory and we can later on change it > from the tarballs > to the unpacked code it we see demand for it. At the moment > it's just easier > to keep the tarballs and focus on other work. > > > > > > 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. > > > > agree, we don't really loose anything, can change if > necessary and can > continue with our work > > Juergen >
