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

Re: build_tree_from_entries

From: Sam TH <sam_at_uchicago.edu>
Date: 2001-04-27 00:47:24 CEST

On Thu, Apr 26, 2001 at 05:14:13PM -0500, Ben Collins-Sussman wrote:
> Sam TH <sam@uchicago.edu> writes:
> > Read an entries file.
> > Seperate the files and dirs.
> > For each file, add it as a child.
> > For each dir, recurse to that dir.
> [...]
> > The resulting tree can then be compared against the actual working
> > copy tree. However, this comparison needs to ignore the file
> > contents, since the entries files don't contain those contents. =20
> >
> Hmmm. This isn't the test I had in mind. Again, I was only thinking
> of comparing apples with apples.
> If we're going to examine a set of entries files, I care about a lot
> more than the answer to the question "does its structure match the
> wc?". I care about all the little XML attributes in there -- the
> state flags, timestamps, etc.
> So again, my idea was to build a 3rd type of tree, with its own
> property keys, and compare against an internally-synthesized tree of
> the same type (statically buried in the test.)

Ok, that's clearly an important test (although I'm not sure exactly
what propery info you have in mind). But we definitely need to make
sure that information which is in two places is consistent.

I think this is another place where my overall 'vision' is conflicting
with yours. I think that the entries files and the working copy are
two different 'views' on the same actual data. Through the wc view,
you see some of the properties (file contents, permissions,
structure). Through the entries view, you see others (timestamps,
structure, revision number). But we need to make sure that info you
can get from two places (such as structure [1]) is the same in both
places. Having the metadata be wrong is bad, but having the metadata
be different than the data is maybe worse.

So I think we need to do it both ways.

> > The other outstanding issue here is that we should be looking at the
> > other files in the SVN directory, and parsing them as well.
> Um, not sure we need to. The entries file is the only bookkeeping
> going on. Everything else is data storage. (At most, you'll find a
> journaled log somewhere in there, indicating that the client crashed
> while making atomic changes to data.)

Ok, makes our lives easier. We want to check that text-base is
correct, though.

[1] Note that lots of this info will be potentially available from the
working copy, via keyword substituion for example.
sam th --- sam_at_uchicago.edu --- http://www.abisource.com/~sam/
OpenPGP Key: CABD33FC --- http://samth.dyndns.org/key
DeCSS: http://samth.dynds.org/decss

  • application/pgp-signature attachment: stored
Received on Sat Oct 21 14:36:29 2006

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