Re: [e4-dev] Resources 6-Mar-2009 meeting notes

[James Blackburn <jamesblackburn@xxxxxxxxx>]

2009/3/12 Konstantin Komissarchik <konstantin.komissarchik@xxxxxxxxxx>:
> Essentially an auto merge agent is a script that sits in a loop and polls
> the source control system for changes to integrate. It picks the first
> change (in order) and runs it through the merge process… merge… resolve…
> build… test. If it gets to the end of the process, it commits the change to
> the target branch. If the process fails, the agent gathers the relevant info
> and sends an e-mail to the dev team. I then waits for the change to be
> manually merged before continuing. Rinse and repeat.

Well that sounds ideal (except the Eclipse build server might not like
building on every commit...). What tool(s) are you using to do this?
If the tests pass then the code must work, right ;)?  What do you do
for projects without tests, afaik o.e.ui.ide doesn't have tests(?)?

> It turns out that the vast majority of changes can be integrated safely this
> way with zero manual steps required. One of the reasons that this is the
> case is that the automated agent will likely attempt the merge very soon
> after the original change goes in. This minimizes the potential for
> conflicting changes to build up.

This was the point I was trying to make (and I guess Martin was too)
about merging frequently. If you don't let changes build up, chances
of breaking things is minimised.

> Will not work with CVS.

You could use something like cvsps, or a vcs which does support atomic
patchsets, pull the data form cvs, perform the merge and test and then
spit out a patch at the end if all appears to be ok.

In my mind this all seems possible.  I guess it's a policy decision on
whether it's ok to ever allow non-human verified code into a repo.  At
the very least it could be scripted to do everything but the commit,
and present the committer with a visual diff of the patchset to
consider.

Cheers,

James