fenics team mailing list archive

[Martin Alnæs <martinal@xxxxxxxxx>]

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.

Martin


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