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

Re: unified tree structure

From: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2001-04-27 02:08:45 CEST

Sam TH <sam@uchicago.edu> writes:

> We take a regular working copy. We modify the repository it's from
> via some other working copy. Then we update the working copy. We now
> have a number of representations of what happend.
> 1. The output of 'svn up'.
> 2. The expected changes.
> 3. The changes to the entries files.
> 4. The changes to the actual working copy.
> I really think that it's important that we verify that all of these
> are consistent.

Okay, now I understand your system. :)

It's basically a world based on a single standardized "diff tree".
You create "diff trees" based on the 4 situations above, and compare
them all to each other.

I understand that it has the advantage of potentially being more
thorough and maintainable, but at the disadvantage of being more

The deal is: the testing system I've been proposing is already done.
I can compare "wc trees" to static expected ones, and I can compare
"output trees" to static expected ones. That's *all I need* to write
the tests we so desperately need, so I'm going to stop searching for
the perfect design now.

I'm going to check in the existing system, and a bunch of tests that
use them. If you want to additionally implement your fancier system,
I say "all power to you". Submit patches; just don't destroy or
overwrite the existing system & tests.

We'll probably end up with two different API's for writing tests;
there's certainly nothing wrong with this. Let them both coexist and
be used. (It certainly doesn't hurt to do two different kinds of
testing!) If someday one of them bit-rots or proves unmaintainable,
we'll throw it out. :)
Received on Sat Oct 21 14:36:29 2006

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