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

Re: Why ra_serf should not (yet) be the default WebDAV RA implementation

From: Branko ─îibej <brane_at_xbc.nu>
Date: Sat, 15 Nov 2008 03:22:38 +0100

C. Michael Pilato wrote:
> Justin Erenkrantz wrote:
>> On Fri, Nov 14, 2008 at 10:58 AM, C. Michael Pilato <cmpilato_at_collab.net> wrote:
>>> I pointed you to the editor's provision for so-called "postfix textdeltas"
>>> (but I think you didn't like that the properties couldn't be similarly
>>> handled).
>> (FWIW, it's not a matter of "like", but rather "can't".)
>> I vaguely remember that, but I never understood that suggestion as I
>> believe that clearly violates ordering rule #5. As I've always read
>> #5, you can't call close_directory with any open files left. So, I
>> don't see how this suggestion could work without violating that.
>> (There is no formal reference in the docs to 'postfix textdeltas' so
>> I'm guessing that it's something that technically violates the
>> ordering constraints but is tacitly approved.)
> No, postfix textdeltas were part of the design of the editor, and date at
> least as far back as my involvement in the project (when 'svn' was
> "committing to" and "updating from" XML files).

The way I remember this from way back when, postfix-textdeltas were
invented sort of to make it easier for humans to debug those XML files
... and to allow conflict detection before the bulk of the data was
read? Something like that. I can't recall exactly why the depth-first
editor constraint was put in, except that I do recall agreeing with it
then ... possibly it made our own editors easier to code up at the time,
and made them more "streamy" -- trading efficiency for smaller memory
footprint, most likely.

-- Brane

To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-11-15 03:23:23 CET

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.