Cool idea, but you'd only be able to safely auto-commit IF the upstream
trunk hasn't updated since your last test run succeeded; else your test
results are invalidated and you have to start over again. It'll work up to
a certain scale before we get to the point where changes come in more
frequently than test runs can finish. At that point we will either have to
slow integration pace artificially, or move to the git distributed model
with subsystem maintainers so that we have an average log(n) pulls to trunk
rather than (n) (which introduces a different kind of scalability issue).
On 04/09/2010 04:14 PM, Thomas Diesler wrote:
I've been experimenting with Git for a while and have tried to
setup a
QA based commit policy like this
* Hudson QA runs of a public git-svn repo (1)
* I pull and push to a my public git repo (2)
* I work on multiple local git repos one for office one for home (3,4)
* (1) pulls from (2) and runs the QA
* If QA passes (1) commits to svn
* If QA doesn't pass, the pull is reverted
The idea is that I don't commit to SVN directly. Instead Hudson does
when the changes that it pulled in (from various repos) are ok.
I'll blog about when it proves useful and I get more experience with it.
cheers
-thomas
On 04/09/2010 08:10 PM, Jason T. Greene wrote:
> This is just a friendly reminder that all minor commits (changes
> unlikely to affect others) need to be ran through smoke-tests before
> committing.
>
> Everything else needs to have a full testsuite run *before* committing.
>
> This can be done by either running it locally on your box, or you can
> commit to a private branch and create a temporary hudson job.
>
>
--
- DML ☍