2014/1/10 Mathias Behrle <[email protected]>: > * Albert Cervera i Areny: " Re: [tryton-dev] What is your internal > workflow" (Fri, 10 Jan 2014 15:44:49 +0100): > >> 2014/1/9 Mathias Behrle <[email protected]>: >> > * Jean C: " [tryton-dev] What is your internal workflow" (Wed, 8 Jan 2014 >> > 09:34:59 +0100): >> > >> >> We are currently using mercurial with bitbucket. We want to try on the >> >> pull-request workflow, but we understood it may be difficult regarding the >> >> way mercurial manages branches. >> > >> > One of your primary decisions will be, if you want to maintain versions >> > older than current. If you want to do so with mercurial, the layout from >> > tryton.org seems still the way to go (while I have to admit, that it is >> > looong ago, that I looked at the branching capabilities of mercurial). >> > Publishing on the usual hosters will be tedious. >> > If you don't intend to do maintenance of different versions, you can choose >> > the same way as Zikzakmedia and NaN·tic and just publish the current >> > branch. >> >> Note that we created 3.0 branches for all repositories, and will add >> 3.2 when it is released, etc. > > Good news. Looking forward to your experience with series maintenance on > 'real' > mercurial branches. > I suppose, you meant that you currently work on default = 2.9/3.0 and that you > will branch as soon as 3.2 is out (apart from account_es*, which have 2.8, > like > Sergi said)?
I didn't mean that but that's how we work, yes. I thought we had already changed that... > I agree, that the choice of VCS is mostly a matter of habit. > Out of interest I made a short test on branching and transplanting with > mercurial. As long as you intend to work with persistent branches, there seems > no problem. What I am really going to miss for my everyday work is the removal > of a (feature/hotfix/whatever) branch. It seems in mercurial you only can > close > them and they will be in history forever. Perhaps I am not using the right > workflow, because I am accustomed to git. > Not a point in publishing series branches, but important for me in daily > development. That's how we've been working with git in OpenERP too. One idea we had was to use rietveld for that and just making it easy to pick those reviews with the scripts we use. This way we can easily pick a patch that traverses several repositories + adds a module. That has the disadvantage of developments that depend on other developments, though. > > > -- > > Mathias Behrle > MBSolutions > Gilgenmatten 10 A > D-79114 Freiburg > > Tel: +49(761)471023 > Fax: +49(761)4770816 > http://m9s.biz > UStIdNr: DE 142009020 > PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6 -- Albert Cervera i Areny Tel. 93 553 18 03 @albertnan www.NaN-tic.com
