On 10.01.2014 17:30, Mathias Behrle wrote: > * 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 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.
Maybe you should have a look at Mercurial Queues as an alternative to Git's feature branches. I often use a short series of 1-5 patches (which might be folded into a single patch eventually) when developing a new feature. -- Freundliche Grüsse Robin Baumgartner Software Engineer Leuchter Open Source Solutions AG Winkelriedstrasse 45 CH-6003 Luzern [email protected] tryton.leuchterag.ch T +41 41 226 50 93 F +41 41 226 50 51 Ein Unternehmen der Leuchter IT Solutions Gruppe
signature.asc
Description: OpenPGP digital signature
