One last bit, then mebbe I can get some coding done...
[ two weeks of email and no code... sigh ]
On Sun, Dec 31, 2000 at 12:54:41PM -0600, Karl Fogel wrote:
> Greg Stein <gstein@lyra.org> writes:
>...
> > It is because the original premise was that the revision number is embedded
> > within the *opaque* version resource URL. To get all of those updated, they
> > must be sent from the server. There is a tradeoff on request size vs
> > response size as long as that revision number is in there.
>
> Oh -- I wasn't aware of this premise. Why is the version resource URL
> opaque?
That is its definition. It is a value provided by the server, indicating
where the client can pick up a particular version of the resource (rather
than just the latest).
http://www.lyra.org/repos/foo.c
http://www.lyra.org/repos/$svn/ver/73.5/foo.c
The former will return the "latest", while the latter returns a specific
version of foo.c.
> There are two pieces of data being stored per entity:
>
> a revision
> a path
3) a version resource URL [needed by the network RA]
Note that the path is actually a URL -- the first of the two listed above.
(3) is the latter of the two above.
> The fact that the storage method is to put them both in a single URL
> doesn't make us somehow unable to change the revision independently of
> the path, or of the rest of the URL.
If the client is going to munge (3), then we will restrict how the server
can do things. Keeping it opaque frees the server to manage those URLs
however it sees fit. You're arguing for tighter coupling of the client and
server if you want the client to manipulate the VR URLs.
> > To resolve the situation, I asked whether it seemed reasonable to put the ID
> > into the URL instead. There is a small operational change to the FS API, but
> > not a lot.
>
> That's crossing a dangerous boundary, though. Now the WC is aware of
> something other than just paths and revisions. The filesystem is no
> longer free to change its internal representation without obsoleting
> zillions of working copies.
The WC is not aware of anything other than revision and URL. The RA layer is
aware of the VR URL. But it sees those as opaque values passed out by the
server.
The server *can* change its internal representation. And yes: that can have
an impact on the version resource URL, which could invalidate a WC. But any
change to the VR URL format can do that. Heck, just changing the
SVNSpecialURI config option on the server would do it. But this is NOT a
problem. The VR URL is a *cached* value. We can easily refresh those *if* we
ever invalidate them with a major server change.
[ a refresh simply involves fetching them again; we cache them to minimize
network traffic at commit time ]
------
[ this last bit is how to get and set the "current" revision during an
update... ]
> > If you waited for an "out" argument, then you'd need to walk the WC again to
> > set the revision information.
>
> Nah, if I got the out arg early instead of late, I could do it as part
> of the edit, i.e., within every replace_directory(), no extra walking
> necessary.
That feels ooky to me. The timing is "out of band" and feels like a bit of
a hand-waving "hope we get it soon enough" thing :-)
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Received on Sat Oct 21 14:36:18 2006