[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: Karl Fogel <kfogel_at_red-bean.com>
Date: Mon, 17 Nov 2008 00:46:35 -0500

Branko Čibej <brane_at_xbc.nu> writes:
> 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?

Yes, precisely the latter. (Nothing to do with readability, AFAIR.)

> 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.

The depth-first constraint has always been there, and I think it was
added mainly by instinct (Jim Blandy's, though many of us felt the same
way at the time). It may be that he wanted to be able to make
guarantees about the "size" of the edit not exceeding the depth of the
tree at any given time or something like that.

Despite having praised the decision in print :-)
(http://www.red-bean.com/kfogel/beautiful-code/bc-chapter-02.html), I'm
no longer so certain of our wisdom. Greg Stein may be right that
allowing random access would be better. I still like the predictability
of depth-first, and the way it eases implementation choices.

One nice thing about the death of the printing press is that it will no
longer be possible to make mistakes in print. I'm really looking
forward to that.

---------------------------------------------------------------------
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-17 06:46:49 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.