Re: test suite progress

On Tue, Apr 24, 2001 at 09:50:45AM -0500, Ben Collins-Sussman wrote:
>
> Hey Sam --
>
> So I finally reviewed (and hacked upon) your python submissions. :)

Great.

> Let me say right off, your ideas are great. They spurred me and Karl
> into a conversation about exactly what kind of information we want to
> reap and examine in the testing system.

Thanks

> 2. Verifying the working copy itself.
>
> Every time a subcommand could potentially change something on
> disk, we need to inspect the disk. Specifically, this means:
>
> * user-data: we need to make sure the working copy has
> exactly the tree-structure we expect, and each file has
> exactly the contents we expect. We also need to look at
> all user-specified properties.

Question here: how do we want to compare file contents? I see two
options -

1. Use cmp.cmp().
 + Exact comparison.
 - Can't be stored in the tree structure.
 - Potentially slow.

2. Use md5sums.
 + Faster.
 + Can be stored in tree.
 - Could be wrong.

Personally, I prefer the latter, since it allows us to maintain my
tree work. If people have strong feelings about the correcness issue,
I would suggest using md5sums for most things, and then having
seperate tests which use cmp() for extra accuracy.

> * metadata: we need to examine all the 'entries' files and
> make sure they have all the attributes we expect.
>
> Your tree idea is great, since it covers both classes of
> verification. It's a superset of what I had been working on, which
> only covered the first class of verification.

I'd like to also point out that the second class is inifinitely more
important. If subversion reports no info, or even bad info, people
will file bug reports. If it corrupts or loses data, people will
simply not use it.

> Here are some of the changes I have made while integrating your tree
> stuff. I mainly had to "expand" your treenode class a bit to cover
> the 2nd category.
>
> * added more 'content' fields to the treenode, as described in README
> * indented code to svn standards. :)

For some reason, Emacs didn't like the idea of switching that file. :-(

> * wrote a comparison func for 2 treenodes

What exactly does this do that compare_trees() and node_is_greater()
don't do?

> * compare_trees() now returns 0 if trees are equal -- this is to
> be consistent with the sorting func and comparison funcs elsewhere
> in this suite.

Personally, I think this should be the other way around, since 'false
== equal' seems counter-intuitive to me. But I don't really care.

> * tree_is_greater() renamed to node_is_greater(), since we're
> comparing nodes. (the original name implies recursion.)
>
> All in all, great stuff Sam!
>
> Changing topic...

Yeah, you're right. See my other messages on this.

> There will be some large commits from me later this afternoon, so hang
> tight.

Goody. I'm eager to see what you've done.
           
sam th --- sam_at_uchicago.edu --- http://www.abisource.com/~sam/
OpenPGP Key: CABD33FC --- http://samth.dyndns.org/key
DeCSS: http://samth.dyndns.org/decss