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