On Tue, Sep 24, 2002 at 01:54:11PM -0500, cmpilato@collab.net wrote:
> Brandon Ehle <azverkan@yahoo.com> writes:
>
> > >Well, it's not that bad. An svndiff against /dev/null is still a
> > >self-compression, and should trim a good amount off the size of a text
> > >file. (It may look like the whole file is there as fulltext, but if you
> > >page down a bit, you'll most likely start seeing some gaps.)
> > >
> > >Still, this is pretty dumb when we're using ra_local. Not sure what the
> > >best fix is.
> > >
> > Won't this also be a problem when you are connected over a LAN as
> > well?
>
> Hm... perhaps just a --fulltext option would work. Even places that
> are *supposed* to send diffs (updates, commits against previously
> existing things) shouldn't care if those "diffs" are just svndiff
> blobs with all "new data".
>
> It'll be kinda like the opposite of CVS's -z option.
For the network case, we can easily distinguish between a fulltext and an
svndiff (whether than svndiff is fulltext or not), based on the MIME type
that is associated with the response. That means we don't have to get too
sneaky with embedding a fulltext within an svndiff just to appease some
expectation of a response to be svndiff.
Regardless, Karl's point about "change #6" is correct, and I'm glad to see a
real-life case where it is needed (my prevoius use-case was simply
debugability and future format convenience, which isn't all that strong).
ra_local would get a chance to say "no source? okay. that's a full text,
let's just stream the sucker rather than worrying about a self-diff".
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Sep 25 00:46:58 2002