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

[Oliver Sander]

Hi Martin,
I think your short-term proposal is a very good idea.  You still
may want to try git or git-svn, because it makes working with branches
and keeping them up to date much easier.  Maybe something can be done
to have commit emails also for git-svn remote branches?
Best,
Oliver

Am 06.05.2012 19:03, schrieb 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
>>
>