[Dune] [Dune-Commit] dune-grid r8042 - branches

[Martin Nolte]

Hi Christian,

either I will push them to a feature branch or publish a suitable patch on the 
FlySpray for discussion. So, you don't need to do cherry-picking yourself.

The problem with special purpose branches is that you can develop only one 
feature at a time. This is good as long as we only develop stuff that has 
previously been discussed (like returing the geometry as an object). But for 
undiscussed ideas you would need several branches and having all of them merged 
into your working copy is simply impossible.

Partly, I'm trying to do what Oli suggested: use git. Only, I try to mimick the 
git development model using svn, so that you can see what I'm doing (if you are 
interested, that is). As far as I understand, in git every developer would have 
his own branch and we would have to do exactly what you just disliked: Picking 
the good stuff from other peoples development branches.

In summary, the branch serves two purposes: On the one hand, we see how the 
developers react to such a git-like approach and on the other hand I can keep 
all my changes under revision control (the last patch I commited is over two 
years old and luckily I still have it).

Maybe we can discuss our development model on the next developer meeting. My 
impression is that some developers feel DUNE is too mature to have a single 
development branch where commits happen sometimes with and sometimes without 
prior discussion. On the other hand, there are developers (like me) who think 
the current strategy is too restrictive for active development (feature request 
remain unanswered and if you just commit changes, you're called autocratic). If 
this judgement is correct, I see real need for discussion.

In any case, a separate development branch is a solution for me (personally). 
But better suggestions would be very welcome.

Best,

Martin

On 05/06/2012 06:09 PM, Christian Engwer wrote:
>>  From my side there would be no problem switching over to git. The
>> only thing that is important to me is to know what my fellow
>> developers are currently working on (e.g., through a commit mail
>> system).
>
> if we should decided, based on the content of the branch, whether we
> like the referencelement chnages or not and discuss possible
> improvements, it would be good to keep the branches as close as
> possible. up to now you only applied other changes. At least some of
> these changes would be nice to have in the trunk.
>
> I must admit, I don't understand the desired development model.
>
> I will not follow a "private" branch in order to do cherry picking. I
> thought we wanted a feature branch. If you prefer developing in a
> private branch, this is OK as well, but I suggest to push the
> necessary changes to a feature branch after you consider the ready.
>
> Christian
>

-- 
Dr. Martin Nolte <nolte at mathematik.uni-freiburg.de>

Universität Freiburg                                   phone: +49-761-203-5630
Abteilung für angewandte Mathematik                    fax:   +49-761-203-5632
Hermann-Herder-Straße 10
79104 Freiburg, Germany