On 8/10/07, David Glasser <glasser@davidglasser.net> wrote:
> It doesn't necessarily seem to me that bottlenecking on
> change_dir_prop is such a big deal... it's not like they are going to
> be the bulk of the checkout, no?
Following a strict depth-first rule, you can't issue any editor drives
- such as opening a file, etc, etc. until that directory properties
are completely fetched and the directory is closed. Thus, you must
halt fetching all files until the directory is closed - this halts the
pipeline.
Also, I'm not sure that a strict reading (in contrast to C-Mike's
interpretation of the exception at the end of the comment block)
permits more than one file to be open at a time:
* 5. When the producer calls @c open_file or @c add_file, either:
*·
* (a) The producer must follow with any changes to the file
* (@c change_file_prop and/or @c apply_textdelta, as applicable),
* followed by a @c close_file call, before issuing any other file
* or directory calls, or
As such, I don't think you can call apply_textdelta *after* calling
close_file - in fact, libsvn_wc (close_file in update_editor.c) would
indeed break in this case - as it does the MD5 checksum there and if
the file isn't updated yet, a checksum mismatch is thrown. So, no,
I'm fairly sure that close_file() can only be called after the
textdelta is complete - hence the earlier parallelization suggestion
wouldn't work in practice (but perhaps in theory!).
FWIW, serf respects this particular constraint, but just assumes it is
okay to have multiple dirs open at the same time. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Aug 10 18:08:03 2007