RE: Auto-version corrections

I'll stand by Greg and Geoff here;  option 1 allows a server to require
that the client be versioning-aware in order to make any changes to the
resources.  That can be a very useful feature.

Geoff, in your original mail on this topic, you said that this was text
for section 3.1.2.  Does that mean that the proposed auto-version
clarification is not part of Core?

I think it does make sense to talk about checkin/checkout in Core, even
if the CHECKIN and CHECKOUT methods are not defined in core.  Actually,
I'd support the auto-version stuff and CHECKIN and CHECKOUT all being
part of Core.

lisa

-----Original Message-----
From: ietf-dav-versioning-request@w3.org
[mailto:ietf-dav-versioning-request@w3.org]On Behalf Of Jim Amsden
Sent: Wednesday, February 14, 2001 2:27 PM
To: ietf-dav-versioning@w3.org
Subject: Re: Auto-version corrections



>...
> You could also consider removing the first item. A core versioning
server
> that supports the checkout option should still support locking
semantics.

Says who? That is a silly statement. Subversion isn't going to support
locking semantics at all. You'll get a 405 if you send a LOCK or UNLOCK.
Versioning servers don't need locking semantics -- they allow multiple
people to work on resources simultaneously. Think, "parallel
development".
That is the antithesis of locks.
<jra>
Maybe I wasn't clear enough. A core versioning server that *supports
locking AND* the checkout option should continue to support its locking
semantics. I didn't mean to imply that a server that didn't support
locking but did support the checkout option needed to support locking.
Note that locking is still optional even  though its referenced in core
since its optional in 2518. So I still think the first item could be
removed.
</jra>

Received on Wednesday, 14 February 2001 19:40:19 UTC