Den 7. nov. 2011 kl. 21:41 skrev Anders Logg <[email protected]>: > On Mon, Oct 31, 2011 at 04:00:18PM -0700, Johan Hake wrote: >> On Monday October 31 2011 15:20:21 Martin Alnæs wrote: >>> I'll just comment quickly on the bzr vs git workings for those who care. >>> >>> Main point: in bzr you fetch one branch at a time (afaik*), while in git >>> you often fetch a repo with multiple branches. This changes how branches >>> are used. >>> >>> *Please prove me wrong :) >> >> While this is true, you can use >> >> bzr init-repository >> >> to connect a set of branches to a shared repor, which typically is a >> development branch. This to share space for the different branches. But AFAIK >> the shared branches are not per se connected to the development branch >> (repo), >> they just share most of the revisions. > > Yes, I use this for sharing revisions between many branches, in > particular > > trunk > trunk-logg > 1.0.x > 1.0.x-logg
That is just a local optimization, doesn't affect my point at all. It is probably hard to appreciate the difference without having worked with git though. The bottom line is I think Andy's git workflow looks great for git, and our new workflow looks good for us with bzr. Martin > -- > Anders > > >>> Den 31. okt. 2011 kl. 20:51 skrev Andy Ray Terrel <[email protected]>: >>>> On Mon, Oct 31, 2011 at 5:05 AM, Martin Sandve Alnæs <[email protected]> >> wrote: >>>>> On 31 October 2011 03:17, Andy Ray Terrel <[email protected]> wrote: >>>>>> Here's the "model" that I've been using on several projects with teams >>>>>> located across the globe. >>>>>> >>>>>> http://nvie.com/posts/a-successful-git-branching-model/ >>>>>> >>>>>> There are a few differences here between the models and I don't know >>>>>> how feasible they are with bazaar. >>>>> >>>>> I see 'master' here as an alias for 'the latest tag in the latest >>>>> release branch'. We want to keep the release branches to allow easy >>>>> hotfixes towards any previous release later. I think that is valuable, >>>>> and I don't see what having the master branch solves? >>>> >>>> So this is a detail that is particular to git maybe. Basically the >>>> master branch is a "clean" trace of the patches made to the code base. >>>> It gives a single line of how things are developed, rather than >>>> having to jump from branch to branch to see what happened. >>> >>> Ok. In bzr, -no-ff is how merge always work, so if you always merge in the >>> right direction you get the equivalent. If merges are sometimes done in >>> the 'wrong' direction, I think master could play a similar role with bzr. >>> >>>>>> 1) Feature branches for work allows for multiple people to be working >>>>>> on different parts of the code easily >>>>> >>>>> We do something like this regularly, but I think we mostly use >>>>> personal branches with no feature name though. There could be >>>>> improvements to the way we use these branches. >>>> >>>> So github does the publication of these branches really well. For >>>> example in SymPy, we can see what people are working on by just >>>> fetching their repos. >>> >>> In bzr, you never fetch a repo, you just get a single branch. This is the >>> most important difference. But you can see on launchpad all personal >>> dolfin branches there by going to the dolfin page and clicking 'code'. >> >> I have most of the other's branches locally on my computer, and can easily >> check out what they are doing. >> >> Johan >> >>>>>> 2) Keep the hotfixes on a branches that are pulled into both the >>>>>> mainline development and the stable release >>>>> >>>>> With the model Anders posted we would do hotfixes in the release >>>>> branch and make a 1.0.x bugfix release. This would be merged into >>>>> mainline (trunk). No need for a separate hotfix branch, since the >>>>> release branch should have only bugfixes for that release. >>>> >>>> So it looks to me like a hotfix in Anders model, requires every active >>>> branch to have the patch applied. Here you make a branch for the >>>> hotfix, review the fix, put it in the active dev and master (which is >>>> really a stable mainline), and finally delete the branch. This model >>>> tries really hard to avoid the SVN style branches that live forever >>>> with only the dev and master being permanant. Anders model looks to >>>> me that you will have a lot of branches in a small amount of time, but >>>> then again I could not be seeing that particular detail. >>> >>> We will have a few new branches each year, but those just stay on launchpad >>> and don't follow a repo around like in git. And branches that stay around >>> for however long we want them to is a feature in our model, allowing easy >>> hot fixes towards any previous release branch. We could delete them when >>> obsolete, but there's no value in that since they just stay on the server. >>> >>>>>> 3) Trims branches as soon as possible so you have a clear >>>>>> understanding of where work is going. >>>>> >>>>> I think we understand where work is going with the new model: Features >>>>> go into trunk, and only bugfixes in release branches. >>>>> >>>>> To reduce the cost of keeping release branches 'forever', we may mark >>>>> old releases as obsolete in launchpad at some point and stop fixing >>>>> bugs. >>>> >>>> Yes but won't they show up forever in bzr? >>> >>> Only on the launchpad server. >>> >>>>>> Anywho, my thought has always been that FEniCS model makes it >>>>>> difficult for non-(Simula + Garth's lab) to contribute. I've actually >>>>>> had people tell me this at conferences. But then again I've also been >>>>>> told that FEniCS doesn't want users as well. >>>>> >>>>> Not sure what the "FEniCS model" is here, but maybe that's part of the >>>>> problem? >>>> >>>> Well it could be more my problem, but more I meant "the way FEniCS is >>>> currently developed." >>> >>> We weren't all happy ourselves, so hopefully the new model is a big step in >>> the right direction. >>> >>> Martin >>> >>>> -- Andy >>>> >>>>> Martin >>>>> >>>>>> -- Andy >>>>>> >>>>>> On Fri, Oct 28, 2011 at 5:06 AM, Anders Logg <[email protected]> wrote: >>>>>>> Dear all, >>>>>>> >>>>>>> There has been some concern regarding the lack of predictability in >>>>>>> FEniCS releases. Yesterday, some of us at Simula met to discuss what >>>>>>> can be done to improve the situation. The result is the following >>>>>>> >>>>>>> draft for a future development model: >>>>>>> http://fenicsproject.org/contributing/development_model.html >>>>>>> >>>>>>> Please comment on the draft and suggest corrections. >>>>>>> >>>>>>> The new development model calls for a "release manager" to coordinate >>>>>>> each stable release (currently 1.0). I can volunteer to serve as >>>>>>> release manager this time. I'd be happy to step aside if someone else >>>>>>> is motivated. >>>>>>> >>>>>>> I know some of you, in particular those from Simula who helped draft >>>>>>> the proposal, have already said OK, but please respond anyway for the >>>>>>> record. >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Mailing list: https://launchpad.net/~fenics >>>>>> Post to : [email protected] >>>>>> Unsubscribe : https://launchpad.net/~fenics >>>>>> More help : https://help.launchpad.net/ListHelp >>> >>> _______________________________________________ >>> Mailing list: https://launchpad.net/~fenics >>> Post to : [email protected] >>> Unsubscribe : https://launchpad.net/~fenics >>> More help : https://help.launchpad.net/ListHelp >> >> _______________________________________________ >> Mailing list: https://launchpad.net/~fenics >> Post to : [email protected] >> Unsubscribe : https://launchpad.net/~fenics >> More help : https://help.launchpad.net/ListHelp > > _______________________________________________ > Mailing list: https://launchpad.net/~fenics > Post to : [email protected] > Unsubscribe : https://launchpad.net/~fenics > More help : https://help.launchpad.net/ListHelp _______________________________________________ Mailing list: https://launchpad.net/~fenics Post to : [email protected] Unsubscribe : https://launchpad.net/~fenics More help : https://help.launchpad.net/ListHelp
