On 7/31/07, David Glasser <glasser@davidglasser.net> wrote:
> Hmm; are you planning to support --svnpatch for repos/repos diff? If
> so, putting the svnpatch code in libsvn_wc seems ill-advised. (Maybe
> you're just planning to do wc-related diff for now?)
As discussed on IRC last day, supporting --svnpatch can be done in two
ways. The first one was to furnish libsvn_client with rich callbacks
-- augment svn_wc_diff_callbacks2_t would end up looking just like
delta_editor functions. This is how I had started implementing until
we discussed. The other one was to take advantage of the various
kinds of editor drives happening in the underlying layers (libsvn_wc
for wc/wc and wc/repos diff, and likely libsvn_delta for repos/repos).
So step by step, it's moving toward supporting --svnpatch for the
three kinds, and this commit is step one. Then I'll join as much code
as possible to optimize code-share. And as far as I've investigated
those three parts, I'm sure wc/wc diff was the tricky one by far as
opposed to wc/repos and repos/repos diff, as we're already doing
*true* editor drives in there. The marshalling routines are set up
now, and this code can be shared. And we did end up Just a matter of
days before this branch supports wc/repos and repos/repos :-)
(And I recall I have to fix the diff_svnpatch test as you suggested,
i.e. have the unencoded stream literally in the code, and use python
libs to compress and encode it on the fly to test against.)
Cheers,
Charles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jul 31 11:05:04 2007