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

["Konstantin Komissarchik" <konstantin.komissarchik@xxxxxxxxxx>]

> Well that sounds ideal (except the Eclipse build server might not like
> building on every commit...). 

Well, there is a separate problem of not releasing after every commit. The
underlying implication is that it's ok to break the HEAD build between
commits. For most eclipse projects that follow this process, you would
probably want to run auto merge on code releases rather than code commits.

Not sure if that's what you were asking... We have auto merge running on
separate hardware from the CC machines that cover the individual branches.
In particular, the CC machines don't ever see failed merges. They do kick
off when the successful merge is released by auto-merge.

> What tool(s) are you using to do this?

Ant + Ant Contrib + few custom ant tasks. I can share our auto merge agent
implementation if that would benefit someone. Also note that there are
commercial products out there that sell products that do this. I haven't
seen any open-source auto-merge solutions yet.

> 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 all depends on your comfort level needs. Most bad merges are actually
caught by text resolve failing or build failing. Only a very tiny fraction
gets as far as tests and then fails. Also note that from a policy
perspective, auto merge should not be running when the target branch is in
the pre-milestone shutdown state and extra care is taken with every checkin.


In our experience, when looking at the likelihood of introducing problems,
the auto merge has performed somewhat better than a developer operating
under normal development rules. At least, the auto-merge agent always runs
the build and never forgets to commit one of the necessary files. ;)

- Konstantin



-----Original Message-----
From: e4-dev-bounces@xxxxxxxxxxx [mailto:e4-dev-bounces@xxxxxxxxxxx] On
Behalf Of James Blackburn
Sent: Thursday, March 12, 2009 11:55 AM
To: E4 Project developer mailing list
Subject: Re: [e4-dev] Resources 6-Mar-2009 meeting notes

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
_______________________________________________
e4-dev mailing list
e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/e4-dev