Re: Testing the new VC code

[Eric S. Raymond]

Michael Albinus <address@hidden>:
> > Instead of doing one-off tests, please take the amount of time you
> > would have allocated for those and write a Lisp exerciser for the
> > whole edit cycle - registration, checkout, modification, checkin,
> > diff, etc.  The more cases in vc-action you can visit, the better.
> 
> I could do this, using ert. The question is which repositories to use
> for tests. Something to be created on the fly, via `vc-create-repo' and
> friends?

Yes, that way we can do content checks knowing exactly what should be in
the repository after each operation.
 
> That might work pretty well for the backends with a local repository
> (git, bzr, hg and alike), but what to do with the other ones?

Looking...for the following ones, create-repo should just work: git,
bzr, hg, RCS, SCCS, SRC, and (somewhat to my surprise) SVN.

We're missing create-repo methods for arch, mtn, and CVS. These are a
little tricky and need some context other than just a directory to
work in.

What we need to do for CVS is:

1. Create a scratch CVS remote root directory, probably in /tmp; mkdir
/tmp/cvsroot

2. Create an empty module directory with a fixed name (say, 'module') inside
that: mkdir /tmp/cvsroot/module

3. Give it a peer empty directory named CVSROOT: mkdir /tmp/cvsroot/CVSROOT

4. Now, where we actually want to create the dummy local repository, we do this:

cvs -Q -d:local:/tmp/cvsroot co module
mv module/CVS .
rmdir module

After these operations, the CVS subdirectory should have three files in it:

::::::::::::::
module/CVS/Entries
::::::::::::::
D
::::::::::::::
module/CVS/Repository
::::::::::::::
module
::::::::::::::
module/CVS/Root
::::::::::::::
:local:/tmp/cvsroot

A CVS operation in the current directory will then look at the CVS subdirectory,
see the contents of these files, and do the right thing.

Arch is much easier:

1. Create a test repository with a dummy name: tla make-archive foo .

2. Make that our default for future arch operations: tla my-default-archive foo

Mtn is a different kind of tricky.  You need to say 

1. mtn db init --db=~/dummy.mtn

2. mtn --db=dummy.mtn --branch=foo setup .

being aware that this will create an SQL database dummy.mtn under 
~/.monotone/databases that will need to be cleaned up on test exit.
-- 
                <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>