Date: prev next · Thread: first prev next last
2012 Archives by date, by thread · List index


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

Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.