Karl Fogel <kfogel@newton.ch.collab.net> writes:
> Then I tried diffing two arbitrary revisions:
>
> $ svn diff -r 640:660 subversion/clients/cmdline/main.c
> svn_error: #21012 : <Trying to use an unsupported feature>
> diff only supports a single revision
> $
>
> Ah,, okay, we don't support that yet. :-) (Is that next on your list,
> Philip?) Same strategy, I guess: just download both files and diff
> them client side, the downloads can be diffs against the working copy
> revision, and/or one of the downloads can be a diff against the other
> download, whatever works best...
I have been thinking about this, but it doesn't follow on quite so
simply from the current code. The crawler used by diff is the same as
that used by update, however the diff editor doesn't build a new
working copy it just creates temporary files (and they are very
temporary, they get deleted during the crawl). This avoids the need to
create directory hierarchies, admin areas, etc.
As you say there are two (at least) ways to approach this:
Suppose we run two crawlers over the working copy, one for each
revision. Then we need some way to associate the files produced by one
editor with the corresponding files from the other, and as far as I
can see this can only be done after the crawlers have finished. So the
files need to exist after the crawl, and we need to keep track of
where in the hierarchy the files belong. I am not clear how to do
this, as the current diff editor avoids the need.
The alternative is that the first crawler runs over the working copy,
and the editor builds a temporary working copy. The second crawler
then runs over this new working copy and a second editor produces the
required diffs. Now the first crawler/editor is very like the current
update, and the second is very like the current diff, so I can see how
this would work. Lots of lovely code reuse into the bargain. There is
the overhead of constructing a complete working copy, but we need to
store the hierarchy information somewhere and a working copy is
probably the simplest way.
In fact writing this has lead me to conclude that the second approach
is the one to take, having previously been assuming that the first
would be the one!
--
Philip
---------------------------------------------------------------------
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:53 2006