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

RFC: Make apply_textdelta unconditional

From: Greg Hudson <ghudson_at_MIT.EDU>
Date: 2003-05-27 16:37:54 CEST

I've gone around on the apply_textdelta vs. dir_deltas text parameters
issue, and now I think the right answer to this redundancy is to make
apply_textdelta unconditional. (A "status" operation would still
forge an empty delta, just as it does now if the editor requests text
deltas.) The reasons:

  * We always have the out-of-band information necessary to know
    whether we're doing a skeletal edit. (At least, I think we do; if
    I'm wrong, it will come out soon enough when I try to implement

  * As I noted in an earlier thread, even if you didn't have this
    out-of-band information, getting a NULL handler from
    apply-textdelta doesn't allow you to save the cost of computing a
    base text checksum; you already had to provide that.

  * ra_svn can get down to one round-trip delay per file. It doesn't
    make sense to be doing a "skeletal edit" negotiation on each file
    when it's really a property of the edit, not the file.

I'm prepared to implement this change very soon (like, Wednesday, to
give people a couple of days to object); it's most conveniently
implemented with an incompatible ra_svn change as well as an API
change, so doing it before 0.24 would be best.

As an aside, libsvn_fs/tree.c:txn_body_is_different has the following

  /* ### todo: Finish svn_fs__things_different to do the full content
     comparison it was intended to do. */

If anyone ever implemented this todo, it would force a "status"
operation to bear the cost of examining the old and new content of
each potentially changed file. However, now that we have checksums,
we ought to be able to do a checksum comparison instead.

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue May 27 16:38:50 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.