On Thu, Apr 26, 2001 at 08:51:45AM -0500, Ben Collins-Sussman wrote:
> Instead, it's your build_tree_from_entries() function that I just
> discovered and am *really* interested in. Let's start a thread on
> that... I want to understand exactly what it does, and how it can help
> us.
Ok, here's the idea with build_tree_from_entries(). It's job is to
convert a working copy into a tree, but by looking at the entries
files, as opposed to the actual files on the disk. It works like
this:
Read an entries file.
Seperate the files and dirs.
For each file, add it as a child.
For each dir, recurse to that dir.
It's fundamentally the same code as for my build_tree_from_wc
functions, just getting the names of the files and dirs from somewhere
else.
The major current limitations of it is that it doesn't utilize the
'ancestor' field, instead using os.path.join to build the dir to
recurse into. Since we've scrapped the idea of parsing CVS entries
files, using the ancestor field for this should be easy.
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.
The other outstanding issue here is that we should be looking at the
other files in the SVN directory, and parsing them as well. This
brings up another question - what does text-base do? Is it really
another full-size copy of the text in the working copy? That seems
really space-inefficent.
That's about it for build_tree_from_entries().
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