[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: rev 7373 - trunk/subversion/libsvn_client

From: Jani Averbach <jaa_at_cc.jyu.fi>
Date: 2003-10-10 23:59:43 CEST

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?

> 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:

      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
      svn switch $url_to_branches/distreg-jaa-uniq_id . (1
      remote: svntest
      remote: mail -s distreg-jaa_uniq_id svn-breakage < PASS

      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.


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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.