dolfin team mailing list archive
-
dolfin team
-
Mailing list archive
-
Message #21265
Re: Merge problems
On Thu, Feb 03, 2011 at 11:57:36PM +0100, Marie E. Rognes wrote:
>
> On 3. feb. 2011, at 22:21, Anders Logg <logg@xxxxxxxxx> wrote:
>
> > [\snip]
> >
> > Any thoughts?
> >
>
> How about some or all of these:
>
> 1. Not introducing separate developer branches
Too late. ;-)
> 2. Establishing a subset of tests that take a few minutes to run, so that we actually bother to run a set of tests before pushing to the main branch
That would be useful, but it's probably difficult to design such a
test. Perhaps it would be one single main.cpp that does a whole lot of
things.
> 3. Making the test script more intelligent so that only the tests affected by the changes in code are run
Sounds difficult. It would have to be very intelligent.
> 4. Focusing on separating larger changes out into feature-branches (as before instead of personal-developer-branches)
That's good but the problem is often that the feature branches tend to
be long-lived and result in large merges once it's time to merge them
back, and most other developers will not keep track of what's going on
in those branches.
In particular, if I start working on a new feature in a separate
branch, it's likely Garth won't complain about the stuff I add until I
actually merge it into dolfin-main. If, on the other hand, I add it to
dolfin-logg, I signal that I intend to merge it as soon as it passes
the tests and it will trigger early feedback/discussion.
(Maybe I should test this hypothesis by pushing GenericMatrix::operator(i, j)
to dolfin-logg. ;-)
--
Anders
Follow ups
References