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.
I think your misunderstanding Greg's complaint, Jeff. Subversion's
update mechanism doesn't really have a notion "get me the latest
code". When the update begins, Subversion asks for the youngest
revision, and from there on out it requests the files and directories
at that youngest revision. Now, this is (we think) a good thing,
because it means that if someone commits a new revision during your
update, it won't cause parts of your update to get a different
revision than what you'd grabbed already before the commit happened.
Greg's concern is that there is redundancy in the set of our URLs for
a given object. That is, if a file was added in revision 3, and
untouched for the next 6 revisions, it would be completely correct to
ask for that file as:
file URL @ rev 3
file URL @ rev 4
file URL @ rev 5
file URL @ rev 6
file URL @ rev 7
file URL @ rev 8
file URL @ rev 9
All of these are correct. And would actually happen if, say, 7 people
each ran 'svn update' after a different one of the above revisions was
added. What you'd like to happen is that the first guy doing the
updating (after revision 3) would get the contents of the file the
hard way, via the filesystem. But you'd want the next 6 guys and
their updates to simply hit the cache -- after all, the file *didn't
change* in those next 6 revisions. But our URL schema prevents a
caching server from pulling that off, since the cache 'keys' are
different -- they differ by exactly the revision number portion of the
URL, in this case.
Is that any clearer?
---------------------------------------------------------------------
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:32:12 2002