fenics team mailing list archive

[Johan Hake <johan.hake@xxxxxxxxx>]

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 <logg@xxxxxxxxx>:
> > > 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.terrel@xxxxxxxxx>:
> > >>>> On Mon, Oct 31, 2011 at 5:05 AM, Martin Sandve Alnæs
> > >>>> <martinal@xxxxxxxxx>
> > >> 
> > >> wrote:
> > >>>>> On 31 October 2011 03:17, Andy Ray Terrel <andy.terrel@xxxxxxxxx> 
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 <logg@xxxxxxxxx> 
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@xxxxxxxxxxxxxxxxxxx
> > >>>>>> Unsubscribe : https://launchpad.net/~fenics
> > >>>>>> More help   : https://help.launchpad.net/ListHelp
> > >>> 
> > >>> _______________________________________________
> > >>> Mailing list: https://launchpad.net/~fenics
> > >>> Post to     : fenics@xxxxxxxxxxxxxxxxxxx
> > >>> Unsubscribe : https://launchpad.net/~fenics
> > >>> More help   : https://help.launchpad.net/ListHelp
> > >> 
> > >> _______________________________________________
> > >> Mailing list: https://launchpad.net/~fenics
> > >> Post to     : fenics@xxxxxxxxxxxxxxxxxxx
> > >> Unsubscribe : https://launchpad.net/~fenics
> > >> More help   : https://help.launchpad.net/ListHelp
> > > 
> > > _______________________________________________
> > > Mailing list: https://launchpad.net/~fenics
> > > Post to     : fenics@xxxxxxxxxxxxxxxxxxx
> > > Unsubscribe : https://launchpad.net/~fenics
> > > More help   : https://help.launchpad.net/ListHelp
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~fenics
> Post to     : fenics@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~fenics
> More help   : https://help.launchpad.net/ListHelp