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

Re: STATUS: [RFC] modifications to tools/test-script/svntest

From: Branko Čibej <brane_at_xbc.nu>
Date: 2003-10-31 12:03:13 CET

Jani Averbach wrote:

>On 2003-10-31 01:36+0200, Jani Averbach wrote:
>
>I have following system at hand:
>It will first build apr, apr-util and httpd if needed
>
I still don't understand why you want to rebuild httpd. You don't plan
to test against HEAD, do you?

>(1, and after that it will conditionally create a ramdisk for testing.
>After that it will test ra_local, ra_svn and ra_dav.
>
>However I have a problem: =)
>
>1) my plan to use ie. apr/CVS directory as reference timestamp didn't
> work. The timestamp for CVS dir seems to change even with no-op cvs
> operations. Next idea is to use LOG_apr_up file size as indicator
> if src-repo has been changed by cvs. Better ideas, anybody?
>
>
Don't look at the sitze, just grep the contents of LOG_apr_up with
/^[AUP]\ [A-Za-z]/. If you get any matches, something changed in the repo.

>Secondly, Brane, why are you building/doing separete dirs for different
>kind of builds (obj-sh, obj-st)? Why you don't just use same directory
>and wipe it clean between builds?
>
>
Because if something goes wrong with the tests, I have the version that
failed right there for debugging. Otherwise I'd have to rebuild
everything in order to track down a bug. That's why I clean up those
directories at the _beginning_ of a test run, not at the end.

I still strongly suggest against putting the ramdisk logic in the
svntest files. Instead, move obj-sh and obj-st to a subdirectory (say,
obj/st and obj/sh), then just mount obj to tempfs in a wrapper script.
Ramdisk management is way too system-specific.

>Am I missing something, I am? If so please bring some light to the darkness.
>
>
That was about 250 Watts, at a guess. :-)

-- 
Brane Čibej   <brane_at_xbc.nu>   http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Oct 31 12:03:56 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.