Contributors mailing list archives
contributors@odoo-community.org
Browse archives
OCA-Repos: "Semantical Scope vs. Manageability" or "Runbot externalities"
by
dar@devco.co
Hello Friends
a question from Markus (https://github.com/OCA/server-tools/pull/107#issuecomment-112112176) made me think over this topic and I want to share my thoughts at the risk that I have missed any previous discussions or reasoning.
The problem Markus is referring to is here:
https://github.com/OCA/server-tools/pull/107#discussion_r33190164In short (summary from the logs): test may fail because of un-involved (and broken) modules which happen to be in the same repository.
This fact alone is a strong argument in favor of atomic repositories if there wasn't the convenience of automating deployments with pre-grouped sets of modules (I hope I got the reasoning here right).
On the other hand, there are alternatives available, amongst them my favorite would be a oca/oca-dev github user bipolarism as odoo itself has chosen to do. This for the following reason:
"oca" could function as a front-end to the oca codebase, free of too much technical details for the end user (such as all the review process interaction), at the same time it would keep up the actual convenience grouping. A second function would be to receive user feedback on the issue list.
"oca-dev" could function as a place where the review process and interaction during development takes place on atomic repositories (which would comprise one feature which could consist of various modules for modularity, but in the end, should stick to a some kind of "one module - one repository" rule)
Now, the question is, how can oca-dev atomics be included into topic repositories of the oca user?
I think we would have several candidates:
- git submodules seems to have evolved a bit meanwhile.
- subtree merges might come in handy if sub-modules produced folder hirarchy that would be incompatible with the grouping objective (https://help.github.com/articles/about-git-subtree-merges/)
- finally, some maintenance script would be needed in both cases to account for updating subtrees / submodules on all grouping modules, but I suppose this part to be not of any particular complexity.
For a transition, in order to no loose history, I've made good experiences with
git read-tree and git filter-branch which are described in more detail in: http://bneijt.nl/blog/post/merge-a-subdirectory-of-another-repository-with-git/Best Regards
David Arnold
Follow-Ups
-
Re: OCA-Repos: "Semantical Scope vs. Manageability" or "Runbot externalities"
bydar@devco.co- 29/06/2015 05:56:31 - 0 -
Re: OCA-Repos: "Semantical Scope vs. Manageability" or "Runbot externalities"
bydar@devco.co- 29/06/2015 05:33:10 - 0
