Sam TH <firstname.lastname@example.org> writes:
> 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.
I think the answer is: for the *immediate* future, we're just going
to load file contents into a python string and use "==" to test.
(We're only testing on the "greek tree", where file contents are
single strings anyway.)
In the medium-term, we can switch to md5. This will let us test
binary files and overly large files.
> 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.
Good point. :)
> > * added more 'content' fields to the treenode, as described in README
> > * indented code to svn standards. :)
> > * wrote a comparison func for 2 treenodes
> What exactly does this do that compare_trees() and node_is_greater()
> don't do?
I haven't touched these two funcs -- node_is_greater() is still fine
for sorting by name.
Since an SVNTreeNode now contains 'contents' and a property hash, the
first lines of compare_trees() aren't sufficient -- comparing the node
names isn't enough. It now calls a new func that compares *all* the
> > * 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.
Bikeshed. '0' mean success throughout our C testing system, and in
our svn_test_main.py system as well. It's also consistent with Unix
comparison funcs, and even the sorting function you already wrote. :)
> > There will be some large commits from me later this afternoon, so hang
> > tight.
> Goody. I'm eager to see what you've done.
RSN!!! There's a lot of file re-organization going on.
Received on Sat Oct 21 14:36:29 2006