Jan Algermissen wrote:
Julian,
On Dec 1, 2009, at 3:07 PM, Julian Reschke wrote:
Jan Algermissen wrote:
...
Hmm, I think so. The definition in a sense implies that the version
is created as a result of the modification. Which is IMHO *never* the
case for working copies.
Surely the draft must define 'working copy'. What is the nature of a
working copy? What is its true nature? I think: being *used* for
creating new versions. So, what about:
"A "working copy" is a resource at a server-defined URL that can
be *used* to create a new version of a versioned resource."
...
So, substituting "modified" by "used". I'm ok with that.
Fine.
and remove checkout/checkin completely. ('use' instead of 'modify'
sounds less like "The modification cause the versioning" (which it
never does by nature of a working copy (IMHO - s.a.))
If the draft wanted to define it, then it woud be something like:
checkout: an operation on a resource that creates a working copy
checkin: an operation on a working copy that creates a new version of
its corresponding versioned resource.
The issue here is that in some systems, checkout will not create a new
resource, just flip a bit on the versioned resource.
Also, (I think) there are systems where checking in does not create a
new version, but flips a bit on the working resource *making* it a
version (at the same URL).
Thus, defining this would need to be defined in a more generic way. My
attempt:
"Checkout: an operation on a versioned resource that creates a working
copy, or changes the versioned resource to be a working-copy as well
("in-place versioning").
Checkin: an operation on a working copy that creates a new version of
its corresponding versioned resource.
Note: the operations for putting a resource under version control, and
for checking in and checking out depend on the protocol in use and are
beyond the scope of this document; see [CMIS], [RFC3253] and [JSR-283]
for details)."
Sounds good to me.
...
OK, I have added the text as proposed in my copy at
<http://greenbytes.de/tech/webdav/draft-brown-versioning-link-relations-latest.html>,
the terminology section now reads:
Versioned Resource
When a resource is put under version control, it becomes a
"versioned resource". Many servers protect versioned resources
from modifications by considering them "checked in", and by
requiring a "checkout" operation before modification, and a
"checkin" operation to get back to the "checked-in" state. Other
servers allow modification, in which case the checkout/checkin
operation may happen implicitly.
Version History
A "version history" resource is a resource that contains all the
versions of a particular versioned resource.
Predecessor, Successor
When a versioned resource is checked out and then subsequently
checked in, the version that was checked out becomes a
"predecessor" of the version created by the checkin. A client can
specify multiple predecessors for a new version if the new version
is logically a merge of those predecessors. The inverse of the
predecessor relation is the "successor" relation. Therefore, if X
is a predecessor of Y, then Y is a successor of X.
Working Copy
A "working copy" is a resource at a server-defined URL that can be
used to create a new version of a versioned resource.
Checkin
A "checkin" is an operation on a versioned resource that creates a
working copy, or changes the versioned resource to be a working-
copy as well ("in-place versioning").
Checkout
A "checkout" is an operation on a working copy that creates a new
version of its corresponding versioned resource.
Note: the operations for putting a resource under version control,
and for checking in and checking out depend on the protocol in use
and are beyond the scope of this document; see [CMIS], [RFC3253]
and [JSR-283] for examples.
...as always, feedback appreciated,
Julian
