Rick Richardson <rickr@mn.rr.com> writes:
> If tkdiff just parsed the output of the SCM's diff command, that would
> presume that the SCM had a usable diff command. That is not the case
> with all SCM's. Even if it was the case, tkdiff would have to be
> taught how to parse the specific diff output for each SCM. Thats far
> harder to do than to just teach it how to get a file at a specific
> revision level.
Makes sense to me, thanks for the explanation.
> "svn update" already seems to take a -r option. It just needs the -p
> (pipe) option. It wasn't obvious to me where the output file gets
> opened; point me at the place where the output file is opened, and
> maybe I can add it.
Here's the start of the code path you need to look at:
subversion/subversion/libsvn_client/update.c:
See the call to svn_wc_get_update_editor(). The "editor"
referred to here is not a text editor like vi or emacs, it's a
function vtable of type `svn_delta_edit_fns_t'. Subversion
drives the functions in this table to "edit" a directory tree,
including file modifications, adds, deletes, etc. There are
several such editor vtables in Subversion; the particular one
returned by svn_wc_get_update_editor() is the one that updates
things in the working copy when you run "svn up".
So probably svn_wc_get_update_editor() will take a new flag,
`apr_file_t *alternate_output' or something. If non-null, all
file contents get redirected to that pipe and the update does
not affect local revision numbers (same as CVS).
The top-level -p flag would create such a pipe from stdout and
pass it into svn_wc_get_update_editor().
Or something like that, you'll get the idea when you're in the code.
Thanks,
-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:45 2006