Re: Coping with the pull-before-you-push model

On Tue, Sep 14, 2010 at 11:51 AM, Joshua Jensen
[off-list ref] wrote:

 ----- Original Message -----
From: Theodore Tso
Date: 9/14/2010 6:12 AM

quoted

On Sep 14, 2010, at 12:47 AM, Joshua Jensen wrote:

quoted

quoted

Bear in mind that you can still shift to a maintainer model, but keep
the maintainer automated. That is, you can queue up "to-pull" heads, and
then have an automated process pull them one by one and do some basic QA
(does it merge, does it build, does it pass automated tests, etc). Which

Do you know of any existing software that does this?  This may be ideal
in the short ter

Our workflow at $WORK involves pushing changes to gerrit to various
"effort branches", and then once they are approved, we have a "Mergitator"
script that will attempt to merge the effort branch with the merged master
branch, and then attempt to do a build.  If the build succeeds, then the
changes will get pushed back to the publically visible merged master branch,
and then the Mergitator will move on to the next effort branch that requires
merging.   If there is a merge conflict, the Mergitator will refuse the
merge, and then give instructions on how to fix up the tree to avoid merge
conflicts.

How does the integration with Gerrit work here?  The only thing that comes
to mind is that you do something like:

git push gerrit HEAD:refs/for/merged-master

Then the approvals are done.  Afterward, Gerrit merges to the merged-master
branch.

I would suppose an external script is performing regular fetches.  When it
sees new code, it builds.

No, this can't be right, but I'll leave my incorrect workflow here.

quoted

So this probably doesn't help you since I suspect you meant to ask the
question, "do you know of any existing publically available software", but I
can tell you that it certainly can be done, and that software exists.
 Making it be software which is useful and usable to you would definitely
take more work...

It's the branch queueing issue that is my current hang up.  Gerrit's method
is slick, but that won't work outside of JGit.  I'm not opposed to JGit; I
just haven't touched Java in years.

So, perhaps, a web interface where the branch owner selects the (pushed to
central server) branch name that is ready to go.  A merge is attempted.  If
it succeeds, great.  If it fails, then the merge is reset?

Josh
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

In our case we have moved from CVS to git and had pretty much same
problems.  The only difference was that we are working with java and
trying to have every project in separate repository. So we don't have
many commits into common codebase. We have a server keeping bare
mainline repos.
In order to integrate the project with others we are using Hudson CI
which performs builds upon each change detected on the server side
(i.e. mainline repository) and also builds the projects that are
dependent on the one you just changed. Those dependencies can be
described inside each hudson job, but we are using Ivy for dependency
management. If you have good testing infrastructure that is even
better.

So generally the amount of contributors to one project is pretty
small. Some projects are solo, some have small teams coworking on one
project code base.

We are using two main branch model.
The development goes in topic branches. The qa branch is a staging
branch for the changes to be accumulated for the release. People are
using direct pushes to qa branch to integrate or a maintainer. Hudson
builds this codebase. When all release functionality is done the
person responsible for the release is merging qa branch into the
master, which gets released (this must be a fast-forward).

So, i would say component oriented approach is the key here.

HTH,
Eugene