[Dune] suggestion for testing

[Sven Marnach]

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