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

Re: problem with dump/load

From: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2002-07-16 14:22:56 CEST

Greg Stein <gstein@lyra.org> writes:

> On Mon, Jul 15, 2002 at 11:00:48PM -0500, Karl Fogel wrote:
> > cmpilato@collab.net writes:
> > > Ben, Karl, Greg: do you remember why we didn't do this in the first
> > > place? It really *is* a better solution, I think. Was it just so we
> > > could have the conventional "Content-length" header?
> >
> > I remember we did say we wanted that specific header, because it was a
> > conventional name. I think we tried too hard to make everything else
> > extremely minimal, granted that header name, though.
> For a couple reasons that I recall:
> 1) one Content-Length header to specify the body of the "message".
> essentially, by using Headers + Body (length specified by C-L), we could
> get some processing for free from libs that already understand that
> [ possibly a marginal benefit ]

Right... we thought, "hey, would it be nice to have an RFC822 perl or
python parser-library be able to suck up our dumpfile?" So we decided
to glob all of the text and prop content into a single content block
with a single content-length.

> 2) the property parsing doesn't take a length, IIRC, so having the PROPS-END
> was necessary

Once we decided to glob text and props into one block, we needed a
separator between them. "Hey, guess what? Our property-parsing code
*already* expects a PROPS-END. How convenient."

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jul 16 14:25:53 2002

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.