Greg Stein <gstein@lyra.org> writes:
> I want to put the ID into the version resource URL. Before, I was assuming
> that the revision number would go in there. But! If I put the revision in
> there, then I need to update all those URLs on the client whenever the
> server bumps the revision number.
>
> If we do lazy updating on the client, then we get fragmentation. If we want
> to update them all, then the server response grows larger.
It's that last sentence I'm not believing... Why does the server
response have to get bigger? After an update, the client knows that
*every* entity within the update's "purview" is now at the new
revision number. But only entities that actually changed in the
update need space in the server's response.
I'm sorry, I'm totally missing something here.
You don't need to update those URLs; libsvn_wc can do it, you don't
worry about it.
> 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? There are two pieces of data being stored per entity:
a revision
a path
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.
> 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.
> 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.
> > In any case, the local updating of everything to the new revision
> > shouldn't result in any extra network traffic for DAV. The network
> > only mentions the changed entities and the new revision -- the rest,
> > the working copy can deduce for itself.
>
> It cannot deduce version resource URLs.
Huh? Why not? It's just bumping a revision number...
-K
Received on Sat Oct 21 14:36:18 2006