Karl Fogel <kfogel@newton.ch.collab.net> writes:
> Philip Martin <philip@codematters.co.uk> writes:
> > 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!
>
> :-) Hmmm...
>
> Where on disk are these temporary working copies going to be created?
Good question. The current diff editor only ever has a single
temporary file at any one time, so it just uses .svn/tmp. This is
probably where the working copy would go in the absence of any other
choice.
It would be better to have a platform independent interface to a
"temporary area". Something that would allow one to create a temporary
directory with some sort of random name. An addition to apr perhaps?
Can we compare two repository revisions without creating some sort of
hierarchy? I don't really see a way to do that. The scheme above only
requires one temporary working copy, not one for each revision.
--
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