Date: Thu, 14 Oct 1999 23:28:57 -0400 Message-Id: <9910150328.AA19619@tantalum> From: "Geoffrey M. Clemm" <gclemm@tantalum.atria.com> To: ietf-dav-versioning@w3.org In-Reply-To: <8525680B.000EF6E3.00@D51MTA03.pok.ibm.com> (ccjason@us.ibm.com) Subject: Re: Versioning for dummies From: ccjason@us.ibm.com I'm not sure if these are suitable for the versioning mailing list. They seem pretty simple and fundamental, but they don't seem to be clearly answered to me in the versioning doc.... All good questions ... I'll respond to them in the mailing list and see if we can make the answers clearer in the specification. If one checks out resource in a workspace, is one given a new URL to use for the CHECKIN? Or does one just use the URL that one used for CHECKOUT? The latter (i.e. the same URL used for CHECKOUT). The Target-Selector header specifies the workspace that contains the working resource that you want to CHECKIN. If one uses the URI that was used for CHECKOUT, then isn't it possible for the parent collection to go away in the workspace? Yes. But the dav:working-resources property of the workspace gives you a way to always find all the working resources that you have checked out into that workspace. Is is it possible to issolate changes to a workspace to only changes that that were created through the workspace? Perhaps... make the selection rule start with a configuration and then grab the latest of an activity. Yes. Then assign a really unique activity name to the workspace. The current spec only allows one workspace to have a given activity "current" (i.e. being actively updated) at any time. Some have argued against that restriction, but I continue to push for it, since it gives you this "protected world" that you would like. You can also do it with ACL's on the activity, but we don't have an ACL spec yet. As long as noone changes the activity of the workspace (or the rsr), then only changes made within the workspace are visible in the workspace, right? Correct. Is there something in the server that insures that only one revision of a given resource will contain a given label? Yes. That is a required by the protocol. One of the way it is enforced is that there is a dav:revision-labels property of a history resource that is a collection whose members are all the labeled revisions of that history resource, named by their labels. Since a collection can only have one member with a given name, this ensures that only one revision in the history can have a given label. I think you answered this earlier... but the spec talks about a workspace having an active activity. A client can specify an activity on a method by method basis, right? I think we say "current activity", rather than "active activity". What did you have in mind by "specify an activity on a method by method basis"? Can a workspace have more than one active activity? Can a revision be in several activities? Just one. These are actually two ways of asking the same question (since the current activity determines what activity is associated with a working resource, and therefore what activity will contain the resulting revision when it is checked in). The reasons for this restriction is that the purpose of an activity is to track a logical change, and annotating a single version with two activities makes it infeasible to "deliver" just one of those changes to another workspace (i.e. by adding it to the RSR of that other workspace). If a single new revision captures changes from two activities, you must model this as a "do both activities" activity, and have that "do both" activity set to be your current activity. Cheers, Geoff