On Monday November 7 2011 14:28:40 Anders Logg wrote: > On Mon, Nov 07, 2011 at 11:24:12PM +0100, Martin Alnæs wrote: > > Den 7. nov. 2011 kl. 21:41 skrev Anders Logg <l...@simula.no>: > > > 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. > > I know. I just wanted to answer Johan's question which I interpreted as "Is > it safe to use a shared repo to store different branches like trunk > and 1.0.x?"
No question from my side! :) But thanks anyway! Johan > -- > Anders > > > Martin > > > > >>> Den 31. okt. 2011 kl. 20:51 skrev Andy Ray Terrel <andy.ter...@gmail.com>: > > >>>> On Mon, Oct 31, 2011 at 5:05 AM, Martin Sandve Alnæs > > >>>> <marti...@simula.no> > > >> > > >> wrote: > > >>>>> On 31 October 2011 03:17, Andy Ray Terrel <andy.ter...@gmail.com> 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 <l...@simula.no> 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 : fenics@lists.launchpad.net > > >>>>>> Unsubscribe : https://launchpad.net/~fenics > > >>>>>> More help : https://help.launchpad.net/ListHelp > > >>> > > >>> _______________________________________________ > > >>> Mailing list: https://launchpad.net/~fenics > > >>> Post to : fenics@lists.launchpad.net > > >>> Unsubscribe : https://launchpad.net/~fenics > > >>> More help : https://help.launchpad.net/ListHelp > > >> > > >> _______________________________________________ > > >> Mailing list: https://launchpad.net/~fenics > > >> Post to : fenics@lists.launchpad.net > > >> Unsubscribe : https://launchpad.net/~fenics > > >> More help : https://help.launchpad.net/ListHelp > > > > > > _______________________________________________ > > > Mailing list: https://launchpad.net/~fenics > > > Post to : fenics@lists.launchpad.net > > > Unsubscribe : https://launchpad.net/~fenics > > > More help : https://help.launchpad.net/ListHelp > > _______________________________________________ > Mailing list: https://launchpad.net/~fenics > Post to : fenics@lists.launchpad.net > Unsubscribe : https://launchpad.net/~fenics > More help : https://help.launchpad.net/ListHelp
_______________________________________________ Mailing list: https://launchpad.net/~fenics Post to : fenics@lists.launchpad.net Unsubscribe : https://launchpad.net/~fenics More help : https://help.launchpad.net/ListHelp
