Jeff Stuart <jstuart@computer-city.net> writes:
> On Fri, 2002-10-18 at 00:38, Greg Hudson wrote:
> > Unmodified files in tag or branch directories do not have stable DAV
> > version-urls. This could affect the performance of HTTP caches and
> > other DeltaV-based tools, although it does not affect Subversion
> > directly. Read on for details.
>
> Is this REALLY a problem? IE let's assume for a moment the default
> repos structure. IE /Trunk, /Tag, /Branch. I can see caching /Tag.
> But I wouldn't want a cache of /Trunk as by definition, it'll be
> changing. Possibly quickly! The same possibly with /Branch. IE I'd
> always want to make sure I got the latest code from each.
>
> Furthermore, didn't one of the devel team say earlier that
> using/depending on the internal URLs of svn is a BAD thing?
>
> Or am I completely missing the point? :)
Yeah, you are. :)
When you do an update or checkout, your svn client does a GET on a
(revision, path) pair. But *really*, our DAV protocol represents each
such pair with a a special opaque url that represents... well, let's
say it's kinda like the equivalent of an 'inode' in the repository.
So suppose Joe checks out all of (5, /branch/foo). Some caching http
proxy notices all of the inode GET requests and caches the data. Now
Jane comes along and checks out (6, /branch/foo). Perhaps only 3
files actually changed between revision 5 and 6 in that branch;
therefore, Jane's checkout should be GETting the exact same set of
inodes, except for the 3 new ones. This is where the HTTP caching
proxy really speeds things up.
But Greg is pointing out that the 'stable' inode-like identities
aren't really stable when you copy whole subtrees from /trunk to
/branch... which kinda defeats the point of having them at all. If
caching doesn't work, we may as well have people simply GET the (rev
path) pairs directly.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Oct 18 16:36:26 2002