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
tight.
Received on Sat Oct 21 14:36:29 2006