On Sun, Dec 31, 2000 at 07:50:25PM -0500, Greg Hudson wrote:
> > If the revision number is to be updated for an entry, then we must
> > also update the version resource URL. If not... We In Big Heap-um
> > Trouble.
>
> Sorry to continue distracting, but why? We know that the version
> resource URL is still for the same node-revision as the updated entry,
> by virtue of the fact that the server didn't report an update for that
> file or directory. What trouble do we get into by updating the entry
> but holding onto a non-canonical version resource URL?
We use it during the commit process. With the old revision in there, it will
appear out of date.
Hmm... but if the server is doing the double-open-node test, then it will
see there isn't a problem.
It seems you're probably right... at commit time, we should be okay, despite
not having the "right" URL. Given that all other ops are read-only, and that
it would read the correct node, then those may be okay also.
Something might turn up, but it seems fine on the surface. However, there
are still modelling issues within DeltaV with the embedded-revision
semantic. The root of the issue is that you check in a change to foo.c, yet
you get new version resources for *other* things. The ideal from the
modelling issue is the embedded-ID semantic -- it matches DeltaV, we always
have the canonical URL (in the update case above), and we end up with the
minimized sizes for the request/response.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Received on Sat Oct 21 14:36:18 2006