Philip Martin <philip_martin@ntlworld.com> writes:
> On the other hand, if my understanding of editors is correct, some
> sort of editor approach might have benefits. For instance, if
> arbitrary file revisons do need to be retrieved over RA then the
> problem of temp file ownership/deletion goes away: the editor driver
> constructs temp files, drives the editor and then cleans up. I think a
> new editor driver, rather than svn_wc_crawl_local_mods, is required
> though. I am not sure if the "editor" is an svn_delta_edit_fns_t
> either or some other vtable.
>
> Or have I missed the point?
I think you're on the right track, if I understand you correctly. But
there's some code you can already use...
What you want to do is *very* similar to the update process. In that,
svn_crawl_local_mods sends a state report, in which the wc reports its
revision-wise layout to the repos, so the repos can drive an editor
that [talks over the network to another editor, which in turn] updates
the working copy to whatever revision was requested, usually head.
I think you'd want to replace that final editor, the libsvn_wc editor
that transforms a working copy to a new revision. Instead of updating
the wc, it would just show diffs. (Of course, it's libsvn_wc, so it
can't print out the diffs or anything; instead, like you say, it would
construct tmp files or whatever, and then invoke callbacks/batons that
were passed in at editor creation time. Those callbacks would come
from clients/cmdline/ or whoever, and they'd take care of displaying
the diffs in the right way.)
Is this making sense?
-K
---------------------------------------------------------------------
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:36:46 2006