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

Re: RFC: Make apply_textdelta unconditional

From: <kfogel_at_collab.net>
Date: 2003-05-28 07:36:19 CEST

Greg Hudson <ghudson@MIT.EDU> writes:
> Really? Why? Right now, the two bits of information are always in
> sync; we instruct delta_dirs to send a skeletal edit precisely when the
> editor isn't going to request deltas anyway. I can't imagine any
> situation where we wouldn't want them to be in sync. And if you did
> accidentally feed a skeletal edit to a driver which wants text deltas,
> something horrible would happen, like working copy corruption.
> Unless there's a compelling reason for both parties to be in control of
> a negotiation, it's usually simpler and less error-prone for one party
> to make the decision unilaterally.

The more I think about it, the more sense that makes -- specifically,
for the driver to be in control (and not just because it's called "the
driver", but because of what it is). The driver will always know what
it's trying to do. If its task doesn't need text deltas, it can send
the null window. If the task does need them, it should send them.

> That would be terrible. You'd get situations where code can work with
> ra_local (or with ra_dav, because ra_dav is so divorced from the regular
> API) but not with ra_svn. You'd have all this meaningless flexibility,
> with the addition of a big fat land mine which will go off if you ever
> use it.

Hmmm. I have to admit, you've got me there :-).

I think I'm +1 on this (thanks for taking the time to help me work
through it).

I'd prefer for Greg Stein to have a chance to see the proposal. But
he's off at a convention right now, and may need a few days to catch
up with the list. Is your schedule such that you need to do this
change right away?


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed May 28 08:19:19 2003

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.