On Fri, Nov 8, 2013 at 9:47 AM, Michel Meyer <mme...@trobz.com> wrote:
> Hi Community, > > It seems that the module organization is a sensitive subject, but it's > obvious that CVS organization is fundamental for good processes. > > If I can afford, personally i think 1 module = 1 repo should be the rule > (in a perfect world :)). > > I had similar issues in the past on large plugin based projects and it's > always a pain, specially if your repo is getting bigger (like > openobject-addons): > - it's go against the module pattern > - heavy, get all modules when you need only some > - make review process harder (you can't test only one module without being > sure there's no side effect from others) > - it's hard (impossible) to manage version of each module > - merging can be hard/messy > - 1 revision may affect multiple not related modules (up to the dev to > avoid it...) and can produce confusion in logs > > But I may understand also constraints that pushed the community to create > mixed modules repositories, and established processes can not be changed > quickly... > > > > Anyhow, I'm trying to be compliant with community rules, so pratically, > I'm fighting with git-bzr, bzr fast-import, git fast-export, since 2 > days... :) > > What I'm trying to do is to keep my module alone on github, but merging it > on a lp branch based on openobject-addons (for example). > > I would like to have it bi-directional, I mean be able to get any changes > to my module (and only my module) from the lp branch back to my github > branch, and also be able to merge my changes from git to lp... and I'm > trying to not loose revision history in the sync process... > Hello Michel, I think we all followed the same path. I'll save you a few days: use git bzr remote helper and nothing else. It's now inside the core of git recent releases. some doc here http://felipec.wordpress.com/2012/11/13/git-remote-hg-bzr-2/ the advantage of it is that it's really integrated with git data model, so a bzr git clone is something universal people can share easily. Bi-directional is possible, but Github or LP should be a master MOST OF THE TIME. For instance in https://github.com/openerpbrasil/l10n_br_core Github is the master and LP the slave. If some Python/Launchpad diehard propose some MP on LP, we import the branch in the git repo and merge it. It sucks more than a Gihub MP, but it's doable and we did it several times. Instead if you take my server/addons/web Github mirrors https://github.com/akretion/openerp-server https://github.com/akretion/openerp-addons https://github.com/akretion/openerp-web the master is LP and Github is the slave. If I want to upstream a patch, I could do it on Github and push it to LP and get it merged in LP too, but that would be much hassle and two slow for the addons repo because that wouldn't be done with shallow branches all the way. So instead, I take a breath, I go to that Launchpad thing, do the work, and wait my cron git remote helper to push on Github or trigger it manually (but hey a Launchpad MP will take 2 days on OCA to 6 months in the core, so you can wait 2 hours the mirror to take it later ;-) If I need to add a branch like say RS-OCB, I have an easy process for that too, though it's not fully automated. drop me a mail (raphael.va...@akretion.com) if you need some support for that. -- Raphaël Valyi Founder and consultant http://twitter.com/rvalyi <http://twitter.com/#!/rvalyi> +55 21 2516 2954 www.akretion.com
_______________________________________________ Mailing list: https://launchpad.net/~openerp-community Post to : openerp-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~openerp-community More help : https://help.launchpad.net/ListHelp
