openerp-community team mailing list archive

[Georges Racinet <gracinet@xxxxxxxxx>]

On 07/25/2014 12:17 AM, Raphael Valyi wrote:
> Hello Georges,
>
> Kudos for the work. A feature I was thinking about and I'm not sure
> you would be interested in:
> what about having at the workspace root a folder called "patches" with
> the possibility to have one patch file per branch (parts). I prefer
> not having the patch in the parts folder themselves as these folder
> could be reconstructed from scratch and we don't want to put parts in
> the VCS (while patches would be in the VCS).
> I think we may need this at least for us for agility, kind of quick
> and dirty patching until you have more time to investigate, because
> when working for small companies, we aren't always in a situation
> where there is always budget to do the clean thing in time and we
> should still get it working, sometimes in a few minutes. So dirty but
> useful at least for us.
>
> A chance you want that in the core? Do you think it's viable to get it
> as an extension (any pointer?),
We've been using a similar way of doing to apply OPW patches actually a
while ago, using another recipe that lets you use any shell command:

[buildout]
parts = openerp pos_payment_patch

(...)

[pos_payment_patch]
recipe = collective.recipe.cmd
on_install = true
on_update = true
cmds = cd addons-openerp
       patch -N -p0 < ../patches/pos_payment.patch
       patch -N -p0 < ../patches/lp1048547.patch
       patch -N -p0 < ../patches/opw-581757.patch
       patch -N -p0 < ../patches/closing_balance.patch

but one can get really hard to track behaviour if one mixes this with
vcs tracking (not even thinking of merge-ins). Honestly I'm not sure
exactly what are the problems, might be nothing more than the
freeze/release system that refuses local modifications, a true
integration with vcs subsystem would improve on that.

> so the idea would be that right after converging a branch, the vcs
> provider would try to apply the patch if any. We could think about
> plugin with tools like Quilt, but personally I prefer something very
> simple. Quilt is great for a project like Debian that don't easily
> have control of upstream projects,
agreed about Quilt, although I have very few practical experience with
it. I suppose one could also launch it with collective.recipe.cmd.
> but now that we are on Github, it reasonable to create a branch when
> you need it, but still quick and dirty single patch might help for
> quick prototyping and sharing/deploying/testing it.
Indeed, but this is true of any public DVCS upstream (although of course
bzr/lp are cumbersome compared to git).
>
> What do you think?

Well, would collective.recipe.cmd fit your use-cases enough ?


-- 
Georges Racinet
Anybox SAS, http://anybox.fr
Bureau: 09 72 39 50 97 / 09 72 39 13 06
Portable: 06 51 32 07 27
GPG: 0x33AB0A35, sur serveurs publics