Re: Repository back up, but working copy re-checkout needed

Karl Fogel <kfogel@newton.ch.collab.net> writes:

> Ben Collins-Sussman <sussman@collab.net> writes:
> > The bug we're talking about fixing is in the svn client: making the
> > svn client automatically detect-and-regenerate invalidated opaque url
> > caches, so that an old working copy can be updated by a newer
> > repository.
>
> But -- it turns out (Greg Stein just walked in the door, straight from
> the airport) that there's a way to fix this server-side, and we're
> working on it right now. More in a bit...

Yes... here is gstein's explanation:

When the client does a GET and provides a 'base' custom request header
that contains an (old-style) opaque url, it's telling the server:
"hey, I want this file, and here's the version I already have."

At this point, the server has the option of either returning svndiff
data against the base file, or just returning fulltext. It specifies
what it's doing in the GET response.

Greg's server-side solution (which we're testing now) is that if the
'base' header looks like junk, then just return fulltext. It's always
had the right to do so.

[And also: the opaque url cache will be automatically fixed anyway,
because it's already embedded in the update-report-response.]

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jun 18 00:52:46 2002