On 2003-10-10 11:51-0700, Blair Zajac wrote:
>
> In addition to using it for stress tests, how about setting up
> a smoke test bed?
You are talking about that, right?
$svn/tools/test-scripts/svntest
> This would be great for nearing a 1.0 release.
Yes, I have a plans to do following:
1) 32bit svntest'ing
2) 64bit svntest'ing
3) integrate ra_dav to the play
4) perhaps create a trigger that runs those test based on svn-commit
emails. If a lot of people are running the system, it could be a DDoS
device against svn.collab.net...
At the moment I can run both of the ra_local and ra_dav(http) in
total time of <30min, and I don't expect ra_svn will increase that
time very much. So it could be possible to make a system, which
could give almost instant response to the svn-breakage list.
Moreover there would be a system, when this kind of behavior is
triggered by special path (branch) in the repository, so developers
doesn't have to run test in her/his own machine. I have seen
several posts where people are saying that they can't for reason or
another run tests by themselves. So this could be an interesting way
to distribute the regression test efforts. And it should be easily to
be implementable by svn copy and switch. [I have heard that copies
are cheap. =) ]
for example:
local(user:jaa):
svn cp -m '' $url_to_trunk $url_to_branches/distreg-jaa-uniq_id
svn switch $url_to_branches/distreg-jaa-uniq_id . (1
svn ci ...
commit mail(distreg-jaa-uniq_id)->
remote: svn co $url_to_branches/distreg-jaa-uniq_id
or
svn switch $url_to_branches/distreg-jaa-uniq_id . (1
remote: svntest
remote: mail -s distreg-jaa_uniq_id svn-breakage < PASS
local:
happy hacker
svn switch $url_to_trunk . (2
svn ci ...
commit mail(trunk)-> normal dist. testing?
In this scenario there is still a little room that something broke
during switch 2, and therefore need for local testing, but if there is
also distributed checking against trunk, that could be acceptable (commit
to trunk without local checking).
If the test space are divided between responsible (same kind of)
machines/systems, the total time of testing is reduced. This would be
helpful in case when regression testing takes really long time (days).
Even if the subversion community feels that this is not feasible
system for subversion itself, I would like to receive general comment
about the idea (flaws and reasons why this won't work).
Of course this opens a lot of questions about the security of the
model, but if you trust to the community, commit access is restricted
to a small group of people and test have been run by restricted and
unprivileged user, perhaps you could live with the risks.
And secondly, the remote machine should do the switching/checkouting
in a way that doesn't generate insane amount of network traffic
(checkout whole repository) and doesn't cause conflicts.
Thanks,
Jani
--
Jani Averbach jaa@iki.fi +1-303-413 1047
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 11 00:00:38 2003