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

test suite progress

From: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2001-04-24 16:50:45 CEST

Hey Sam --

So I finally reviewed (and hacked upon) your python submissions. :)

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.

Up till now, I had only thought about one class of information we need
to verify -- lists of lines coming from svn subcommands. But your
"trees everywhere" philosophy actually covers a *second* class of
problem that my code was ignoring. Here's an excerpt from the README
(not yet checked in):

  We've identified two broad classes of verification:

  1. Verifying svn subcommand output.

      Most important subcommands (co, up, ci, im, st) print results to
      stdout as a list of paths. Even though the paths may be printed
      out in an unpredicable order, we still want to make sure this
      list is exactly the *set* of lines we expect to get.

  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.

         * 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.

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. :)
  * wrote a comparison func for 2 treenodes
  * 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.
  * 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...

The features you added to allow us to parse CVS Entries -- it's very
neat. But the problem is that we (Karl and I) think it's not
particularly useful. We can't see why we'll ever need it.

cvs2svn will operate on repositories only. I'm guessing that after we
convert a repository, you imagined that we'd check out a CVS working
copy and an SVN working copy, and then compare them?

That might very well be useful in terms of comparing the actual tree
structure and file contents. But there's just no way we can compare a
CVS entries file to an SVN entries file. The only extra info (beyond
the entryname) in a CVS entry is the timestamp and the revision
number. Comparing timestamps won't tell us anything. And CVS
revision numbers (which are per-file) have nothing to do with SVN
revision numbers (which are per-commit.)

So while I hate to say it, while this may have been an interesting
track to follow, it wasn't a useful one. I hope you learned some
python in the process. :)

There will be some large commits from me later this afternoon, so hang
Received on Sat Oct 21 14:36:29 2006

This is an archived mail posted to the Subversion Dev mailing list.