[Dune] suggestion for testing

[Oliver Sander]

Hi!
I agree with Sven in that the amtliche solution would be to have
a special testing branch.  However I think for a project of our size
both Sven's and Andreas's suggestions are overkill.  There is currently
a refactoring of the build system and, yes, there have been disruptive
patches.  But looking at the last years this has been really rare.
I propose the following procedure:
- no additional branches
- get the automated build system running again [in fact, I suppose it
  would have been smarter to have that _before_ starting to tear apart
  the build system]
- post a warning to the list before committing something dangerous.
  In the long run I do not expect this to happen very often.
- If svn-head is broken: do not get mad.  It is a development branch
  after all.  If you need some stability do not update after a warning
  has been issued.  If you needs lots of stability use a release branch.

--
Oliver

Sven Marnach schrieb:
> Hi Andreas,
>
> Andreas Dedner schrieb am Mo, 19. Mai 2008, um 15:51:40 +0200:
>   
>>> Managing patches is actually the job of a version control system.  The
>>> usual way of dealing with this problem is to have a testing branch
>>> where all dubious patches go, people or test suites test this branch,
>>> and patches that are found to be working fine are merged back to the
>>> trunk.
>>>       
>> I agree, but do you have a suggestion of how
>> this can be done without too much fuss?
>> Would this require a development branch in which
>> changes are committed and then they are merged
>> into the trunk after some testing. What would be
>> a good way of doing this?
>>     
>
> That's what I would suggest.  Patches go to testing first, and are
> merged to the trunk if they pass the automatic tests.  Maybe every
> developer should be responsible to merge her own patches to the
> trunk.  Of course this involves to commit every patch twice, but we
> won't be able to solve the problem without _any_ additional work.
>
>   
>> Having a directory of the form
>>   dune.org/patches/today/patch*
>> would perhaps not be perfect but would be easy
>> to get working right a way.
>>     
>
> I see several problems with this approach.  First, it would be more
> work to set it up than my suggestion.  You would have to adapt your
> test scripts to find the correct patches, apply them, deal with
> conflicts etc.  We would have to provide an upload infrastructure etc.
> In contrast, the solution I suggested requires to create a testing
> branch in subversion and tell the test suite to check out the testing
> branch instead of the trunk.
>
> Second, you wouldn't have any help in merging.  Patches can (and will)
> conflict to each other and can conflict to commits that are posted
> after the patch was uploaded.  If some hunk in a patch conflicts with
> a later commit, the patch won't apply.  You have to deal with all
> conflicting hunks manually.  Subversion would perform a three way
> merge and deal with conflicts in the usual way, i.e. writing all three
> version in files an generate a partially merged file with conflict
> markers.  Of course, you could create an infrastructure that keeps
> track of the respective version each patch applies to and write
> scripts to try a three way merge, but that surely would be a lot of
> work to get a functionality svn provides out of the box.  Subversion
> doesn't help you in merging as much as better RCS's, but it is surely
> more convenient than doing everything manually.
>
> I think your suggestion would produce _lots_ of work, much more than
> the way I suggested.  But I have another suggestion that is even less
> work.  The automatic test suite could be modified to create a
> subversion tag pointing to the latest version that passes the test
> suite, and update this tag every time the test suite passes.  So if
> someone just needs a working version, she would know where to look for
> the latest working version.
>
> Greetings from Stuttgart,
>     Sven
>
> _______________________________________________
> Dune mailing list
> Dune at dune-project.org
> http://lists.dune-project.org/mailman/listinfo/dune
>   


-- 
************************************************************************
* Oliver Sander                ** email: sander at mi.fu-berlin.de        *
* Freie Universität Berlin     ** phone: + 49 (30) 838 75217           *
* Institut für Mathematik II   ** URL  : page.mi.fu-berlin.de/~sander  *
* Arnimallee 6                 ** -------------------------------------*
* 14195 Berlin, Germany        ** Member of MATHEON (www.matheon.de)   *
************************************************************************