Karl Fogel <kfogel@newton.ch.collab.net> writes:
> Now, Mike and I have been thinking of ways to unite these two editors
> into one editor that lazily fetches texts from the repository as
> necessary, and otherwise uses text-bases found locally. (Oh, by the
> way, wouldn't it be nice if ra->get_file() took a base revision, so it
> could send svndiff back whenever we have a base text available
> locally?)
I think it can send an svndiff, it just that when it does that it
doesn't reconstruct the full text from the svndiff. The current code
for 'diff -rREV1:REV2' ensures that get_wc_prop returns NULL to
disable the svndiff being sent.
There was some discussion a couple of weeks ago that the failure to
reconstruct a full text was a bug in ra_dav's getfile.
http://subversion.tigris.org/servlets/ReadMsg?msgId=54142&listName=dev
>
> But before I go into the possible editor unification, I'd like to
> describe how this all relates to "svn merge".
>
> We hope to implement "svn merge" by passing a different diff_cmd and
> diff_cmd_baton to the diff editor[s]. The current diff_cmd callbacks
> just print the diff to stdout. For merge, we'll swap in another
> callback instead, one that actually applies the diffs and possibly
> updates the `svn:merge-history' property as well.
>
> That's it. The sole difference between diff and merge will be which
> callback is passed. That's the idea, anyway.
>
> We're not sure that editor unification has to precede the
> implementation of the merge callback. We've been acting like the
> latter depends on the former, but now that I say it out loud, I don't
> see why it has to be so. Perhaps it would make more sense to get
> merge working on top of the current diff editors first, and then see
> about unifying? Perhaps the unifying is completely unrelated to the
> new merge callback?
>
> The reason the unification has been stumping us is that we're not sure
> what's the best way to take advantage of the existing wc tree. We'd
> like to use a local file whenever possible, of course, and fetch from
> the repository only when nothing else will do. On the other hand, we
> need to be able to diff two arbitrary paths at two arbitrary
> revisions, perhaps none of which is related to the working copy
> (indeed, there may be no working copy in that case!).
Well, I sent a mail related to this a while back
http://subversion.tigris.org/servlets/ReadMsg?msgId=55247&listName=dev
This discussed how to use the working copy to get svndiff's from the
server instead of full text. I had a quick stab at implementing the
idea and it appears to work, as far as I could tell the server was
sending me diffs. I didn't purse it any further because I didn't want
to interfere with the diff editor changes that appeared to be about to
happen. My new code was a little clumsy as I recall (I've still got
the patch, I look it out and update it) but that was mostly due to the
existing interfaces assuming that sessions and editors are unrelated.
>
> The issue is not, of course, the command syntax by which we invoke
> diff on two urls at two revisions; that's already been dealt with in
> another thread, and today Mike Pilato even changed the
> svn_client_diff() interface to be ready for such invocations. The
> issue is whether it makes sense to write an single editor that covers
> all the range from use-a-local-file-in-almost-every-operation to
> fetch-all-data-from-the-repository. It feels strange to have two
> editors to do "svn diff", but on the other hand, as we've been trying
> to turn them into one editor, we've really run into a lot of
> difficulty.
>From a dependency point of view alone, uniting the editors would
involve removing the wc editor and putting that behaviour into the
client editor, since the client level ra dependency cannot go into
wc. Don't take this to mean that I think this *should* be done, just
that it is the only way I think it *could* be done.
--
Philip
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:37:06 2006