Eric Seppanen <eds@reric.net> writes:
> I'm evaluating Subversion right now, and have svn 1.1.1 installed
> along with websvn 1.6.1. I have a tree that contains several large
> binary files (8 files at about 400kb each) and I notice that this is
> slow to work with.
>
> The reason: if I ask websvn to show me what changed between two
> versions, it executes the command:
>
> > svn --non-interactive diff -r2:4 file:///my-repos/tree/
>
> ... and the problem is this command takes 5-7 seconds of CPU time to
> complete. All a waste, I think, because it can't actually print
> anything about the binary files other than:
>
> Cannot display: file marked as a binary type.
> svn:mime-type = application/octet-stream
>
> So why does it take so long? I can only guess that it's actually
> chewing on the binary files for a while.
>
> 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.
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sat Nov 20 03:36:09 2004