fenics team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

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?"

--
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