Karl Fogel writes:
> > Is there any way to get svn to not waste cpu time trying to diff files
> > it already knows are binary and undisplayable? Should there be a way?
> >
> > I might even suggest that that's the way it ought to always work.
>
> The optimization you suggest is possible, but surprisingly difficult.
>
> The problem is that the the part of Subversion that fetches the files
> would have to "know" that the diff was being computed by another part
> of Subversion, instead of by some external program that Subversion
> passes off to. (Because in the latter case, you *can* diff files that
> Subversion thinks are binary.) We could do this, but it would be
> tricky to do it without introducing a layering violation. In the
> interests of simplicity, we've unofficially decided not to.
>
> Of course, if there were an easier way, some unexpectedly simple
> patch, then it would be worth it.
What about storing the mime type of an object in the working copy
somewhere. I did a quick check on some of my working copies and found that
the svn:eol-stlye propery is stored in the WC but the mime type is not. If
it were then the client could make the decision quickly.
This wouldn't even require that we make the WC format incompatible. If the
svn:mime-type property is available in the prop-base then we can determine
if we need to do any further processing for diff at all; otherwise we
do the normal path. Or am I (most likely) missing something?
I would think storing the mime type in the WC (as a prop) would be useful
for the (eventual) pluggable diff support. This way the SVN configuration
area can point to a particular diff program for a specified MIME type
which is easily obtained from libsvn_wc.
L8r,
Mark G.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Nov 20 08:50:00 2004