From: "Lisa Dusseault" <lisa@xythos.com>
I believe the requirements for code repositories and the requirements
for document repositories are in some sense incompatible. Thus, the
client can't count on certain things being true for both kinds of
repositories.
As of yet, I don't see these incompatibilities. Document repository
users want to give things human meaningful names. So do code
repository users. Code repository users want to also give some things
stable names. At least some document repository users want this as
well, as reflected by the fact that many document repository systems
today provide immutable stable names for document versions. And for those
document systems that currently do not provide stable names, we have
described a simple technique for "stabilizing" the names (that I
believe you have agreed does not present implementation difficulties).
I don't see a problem/incompatibility here.
We may need:
- "type A" where the client can count on versions being immutable and
version URLs being non-reusable
- "type B" where the client can count on versions being mutable and
version URLs being readable.
I agree the client needs to be able to count on certain behaviour, but
it will have to be a different kind of behaviour depending on what kind
of server it is talking to. Otherwise the needs of document-versioning
servers will NOT be met by the versioning draft.
Just to ring that bell one more time, I agree that type B clients
need mutable (and human meaningful) URL's, but since they can use
version-controlled resource and non-version-controlled resource
URL's for this, I don't see why they need version URL's for this
as well.
Cheers,
Geoff