On Friday 14 September 2007 12:50, Michael Short wrote: > Seems fair, though it is worth mentioning that the installer could be made > automatic for regression purposes (to prevent clobbering any kind of > production installation).
That is certainly possible but would be a significant amount of work. > At the moment the regression scripts reinstall > bacula as a service anyways. I didn't know that. I'm a bit surprised since it is not necessary to run it as a service to do the testing. Regards, Kern > > Sincerely, > -Michael > > On 9/14/07, Kern Sibbald <[EMAIL PROTECTED]> wrote: > > On Friday 14 September 2007 00:46, Michael Short wrote: > > > While doing some further tests on windows I began to realize that there > > > > is > > > > > no reason why the regression scripts should use the source for any kind > > > > of > > > > > testing. The code is compiled on a completely different platform and > > > copying the entire source tree to a different machine/vmware seems like > > > more work than it should be. Perhaps the win32 regression scripts could > > > > be > > > > > configured to use the nsis installer to setup the regressions instead > > > of actually copying the binary files from > > > > bacula/src/win32/installer/release. > > > > > This way doing regression testing would be as easy as copying > > > winbacula-*.exe to a directory and running a batch script. > > > > Why is copying the entire source tree then running a batch script any > > harder > > than coping winbacula-*.exe, installing it, and running a batch script? > > > > There are a number of reasons why we use the full source: > > > > 1. Normally getting the regression scripts and the source that are up to > > date > > are a matter of doing one time at the very beginning: > > > > svn checkout <bacula-source> bacula > > svn checkout <regress-source> regress > > > > then before every regression: > > > > cd bacula > > svn update > > cd ../regress > > svn update > > > > very simple, and can be done by a script. This ensures that you are > > running > > on the current source. > > > > 2. The source code once built provides a nice reasonable test set of > > files for > > backing up and restoring (i.e. it backs up and restores itself). It is a > > known size and a known number of files, and in a known location, so there > > is > > no twiddling with scripts to point to the correct FileSet, and there is > > no searching to find FileSets that are a reasonable size -- not too small > > and not too big. > > > > 3. The regression scripts do not use a production environment, and if > > used carefully can be run on a production machine -- I run my biggest > > regression > > tests on my production backup machine. To do this requires a special > > non-production installation. > > > > The same svn procedure could be used on Win32 to update the source and > > update > > the regress scripts, but there is one problem and that is that the > > released > > version of Win32 is cross-compiled on Linux, so for doing Win32 testing, > > one > > still must pass via a Linux machine to get everything 100% current. > > > > If you have to copy winbacula-*.exe to the Win32 machine, I don't see > > what is > > hard about copying the whole directory tree. With a Samba mount to a > > Linux > > machine, you can script the Win32 machine to automatically pull down a > > pre-build directory. > > > > > The only issue with using the installer is that the installer cannot > > > install everything without user intervention. > > > > I believe that it can since it has command line arguments, but that does > > not > > resolve the above problems. > > > > > Perhaps the installer could > > > be configured to accept user-arguments which specify the different > > > > install > > > > > modes and options. This would solve a number of problems for Win32 > > > regressions and also include testing the installer as part of the > > > regression tests. > > > > > > Let me know if I am not being reasonable with this :P > > > > I don't see that your proposal really solves much other than doing some > > testing of the installer. Regardless of whether you pull a full > > directory (the whole source tree) or only winbacula-*.exe, you must pass > > by a build on > > a Linux machine. > > > > In face, it seems to me your proposal will significantly complicate > > things -- > > read on for the reasons... > > > > The disadvantage of what you are suggesting is that you cannot do > > regression > > testing on a production machine or one that has a FD installation. In > > addition, you would have to make some modifications to the current > > scripts so > > that the multitude of .conf files that the regression scripts use could > > be installed in the right places on the Win32 machine, which is far from > > simple > > since the directory paths of where the conf files are installed are > > dependent > > on the OS version and the language it is configured for. The current > > regression tests pull everything from a single file. > > > > Regards, > > > > Kern > > > > > Sincerely, > > > -Michael ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Bacula-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/bacula-devel
