Here is a brain dump on the relationship between "svn diff" and
"svn merge". I'm fairly confident about the rough outlines, but in
general I want this topic to get a real pounding from the dev list
before we start coding anything. A couple of notes:
- To simplify this description, I'm going to pretend property
changes don't exist for now. They should be a straightforward
extension from any reasonable solution.
- Everything below is unrelated to the purely local "svn diff",
which diffs working files against base texts. Philip Martin
implemented that with a special working copy crawl that calls
back to a diff procedure; it works great, has nothing to do with
the repository, and will remain unaffected by the refactorization
under discussion here.
Okay, now for a little background on the way remote "svn diff"
currently works. Right now, there are two distinct codepaths, one for
partially local diffs, one for purely remote diffs. If you run
svn diff -rN localpath
then we grab an editor from svn_wc_get_diff_editor(), pass it to
ra->do_update, report the working copy's local revisions, and finally
request an update to revision N. The diff editor is driven just as
though it were an update editor, but instead of updating the working
copy, it prints out differences instead (reversed from the update
direction, I guess, but that's a trivial transformation).
On the other hand, if you run
svn diff -rN:M urlpath
then we use a different editor, from svn_client__get_diff_editor()
this time, pass it to ra->do_update, fake a working copy state report
by simply reporting that we have the whole tree at revision N, and
request to be updated to revision M. :-) As it gets the changes, the
editor uses its own private ra session (oops, I forgot to tell you
about that, see var `session2' in libsvn_client/diff.c) to fetch the
"other side" of each diff from the repository, using on-demand calls
to ra->get_file().
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?)
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!).
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.
Maybe the answer is to not worry about the unification issue at first,
and just concentrate on the merge callback. For some reason, Mike and
I avoided that conclusion, partially because we had never been forced
to articulate the avoidance.
Philip, I'm sure you've been thinking about this stuff too; any
insights? And not just Philip, anyone else please chime in too. We
love your eyeballs, but it's your brains we're really after...
-Karl
---------------------------------------------------------------------
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:05 2006