svnadmin dump/load, svndumpfilter regression tests

[Alexander Sabourenkov <sc...@lxnt.info>]

Hello.

I thought on how to check and be exactly sure that the svndumpfilter ( and 
svnadmin dump too) work as expected and came up with the following:

1. Create a test repository. Stuff there several revisions, with 
modifications, copies and deletes.

2. Do a dump/load into another repository.

3. Check out every revision out of both repositories and compare resulting 
working copies. Or maybe export instead of checkout.

4. Repeat step 2 using svndumpfilter. For example:
- filter out a node that has only been modified.
- filter out a node that has been copied
- filter out a node that has been moved
- filter out a node that has been moved and another node was created with the 
same name in later revision
- etc

5. Repeat step 3.

This tests both dump and load operations simultaneously. If there is a bug in 
one of them, somebody will have a harder than possible time hunting it down.

One way to test them separately is to
for load - generate dumpstream, load, query the repo via cmdline client, compare.

for dump - create repo, do some commits with cmdline client, dump, compare.

But this requres dumpstream generator and parser in python. Which will have 
their own bugs.

Any thoughts?

-- 

./lxnt


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: svnadmin dump/load, svndumpfilter regression tests

[Ben Collins-Sussman <su...@collab.net>]

Alexander Sabourenkov <sc...@lxnt.info> writes:

> Hello.
> 
> I thought on how to check and be exactly sure that the svndumpfilter (
> and svnadmin dump too) work as expected and came up with the following:

This is issue #810:  "dumper/loader regression tests sorely needed"

It would be great if you want to tackle this!

Start off by absorbing subversion/tests/clients/cmdline/README;  it
will give you an overview of how our python tests work.

> 
> 1. Create a test repository. Stuff there several revisions, with
> modifications, copies and deletes.

Our test framework already does this for every test.

> 
> 2. Do a dump/load into another repository.

Easily doable;  our test framework already uses dump/load to create a
new repository for each test.

> 
> 3. Check out every revision out of both repositories and compare
> resulting working copies. Or maybe export instead of checkout.

Multiple checkouts will work fine.  And our test framework is already
built around the idea of comparing trees:  disk trees, 'svn status'
trees, and trees that result from parsing 'svn co/up' output.

> 
> 4. Repeat step 2 using svndumpfilter. For example:
> - filter out a node that has only been modified.
> - filter out a node that has been copied
> - filter out a node that has been moved
> - filter out a node that has been moved and another node was created
> with the same name in later revision
> - etc

Sounds good.

> 
> 5. Repeat step 3.
> 
> This tests both dump and load operations simultaneously. If there is a
> bug in one of them, somebody will have a harder than possible time
> hunting it down.
> 
> One way to test them separately is to
> for load - generate dumpstream, load, query the repo via cmdline client, compare.
> 
> for dump - create repo, do some commits with cmdline client, dump, compare.
> 
> But this requres dumpstream generator and parser in python. Which will
> have their own bugs.

No, no need to write a dumpstream generator/parser in python.  The
whole point of our python tests is that the use the binary tools as
"black boxes", just like a user would.  They're already invoking {svn,
svnadmin, svnlook}.  You would just be adding 'svndumpfilter' to the
list.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org