All the extra repositories we have left contain just one module. so It is possible to change the structure of these repository to remove the top-level directory in them, and clone them directly in $core/<module> furthermore, using submodules for them (except translations due to its size) would allow to identify a build point with one single sha, which would make stuff much easier for tinderboxes, jenkins, bisection etc...
The pros: + no more need for ./g + no more need for $(realpath in the build since there is no links left + a build point is identified by one and only one sha, which is imperative to manage a build-farm ( gerrit+jenkins and the ability to test-build every patches) translations will be moved to ./translations but will not be made a submodules due to its prohibitive size. I have not coded that yet, but that will involved a 'bootstrap' script to manage the migration without re-cloning translations that will be run automatically on make (or maybe at the tail_end of configure... not sure yet) The build is pretty insensitive to the translations content. translations has a very low rate of change and is essentially managed by timar (i.e the person that coordinate localization activities with dev). That means that tagging and branching translation in concert with core will require an extra manual step. the added complexity is not _that_ great, and impact mostly Petr and people doing release build. The cons: - cherry picking a patch from 'before' the change to 'after' the change will not work if the patch impact one of these repos (due to the renaming). that can be mitigated with a pre-processing script to change the target name in the patch, since the filename pattern impacted is regular and easy to detect... so a simple sed should do the job - feature branching becomes a bit more cumbersome if you need to branch one of the submodule. it boils down to remember the 'submodules first' rule: you need to settle submodules operations before core. So, for instance when merging back to master you need to merge to master in the submodules then commit core (still in the feature branch) to pick-up the merge change in the submodules and _then_ merge core. - if you want to be able to checkout to a commit prior to the migration point you need to keep clone/* around. The good news is that it work nicely, the only thing to do after a checkout to a point prior to the submodules migration is to recreate the links for binfilter/dictionaries/helpcontent2 that can be done running ./bin/create_bootstrap_links if you want to see what this look/feel likes, see feature/submodules Norbert _______________________________________________ LibreOffice mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/libreoffice
