[Dune] [Dune-Commit] dune-grid r8042 - branches
sander at mi.fu-berlin.de
Mon May 7 14:18:57 CEST 2012
> 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.
> 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?
>> 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
>>> 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.
>>> 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
>>>> 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.
>> Dune mailing list
>> Dune at dune-project.org
More information about the Dune