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

Oliver Sander sander at mi.fu-berlin.de
Mon May 7 14:18:57 CEST 2012


Hi Martin,

> Something else: Do you think we can merge patches 8043 and 8044 to the
> trunk? In my opinion, 8044 should even go into the release.
>
sounds like a good idea.  Please go ahead.
Thanks,
Oliver


> Best,
>
> Martin
>
> On 05/06/2012 07:36 PM, Oliver Sander wrote:
>> 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
>>>>
>>>
>>
>> _______________________________________________
>> Dune mailing list
>> Dune at dune-project.org
>> http://lists.dune-project.org/mailman/listinfo/dune
>




More information about the Dune mailing list