Message-ID: <4FD6422BE942D111908D00805F3158DF0A757D9A@RED-MSG-52> From: Chris Kaler <firstname.lastname@example.org> To: "'email@example.com'" <firstname.lastname@example.org>, Cc: email@example.com Date: Wed, 17 Feb 1999 16:23:29 -0800 Subject: RE: Version issues This is a great discussion! I used the word "complicated" and that probably isn't the right word. What I meant is that I have a store with 1001 files, 1000 of which have been set to specific versions and I want to set the last one to a specific revision, I'd rather issue a SETDEFAULT command for that specific URL than pull the full RSR which includes all 1000 rules, add one, and push the 1001 rules up to the server. Chris -----Original Message----- From: firstname.lastname@example.org [mailto:email@example.com] Sent: Wednesday, February 17, 1999 12:45 PM To: Bruce Cragun Cc: firstname.lastname@example.org Subject: RE: Version issues Bruce, I'm sorry to hear you weren't feeling well, but welcome back! No, you're getting it just fine. For your item 1 below, the default workspace does just what you want. You never even need to know its there. Recall the default workspace has a revision selection rule containing checkedout and latest. For item 2, the model currently allows access through a specific revision name which temporarily overrides the workspace, so this can be done too. If this was all you wanted, then probably workspaces for level 1 would be overkill. But, lets look at some other simple scenarios and see what would happen. Say a development organization finishes work on a milestone and wants some way to refer to the proper revisions. When work continues, these revisions won't necessarily be the latest revision because the resources may have changed in some appropriate way. Configurations solve this in level 2, but a common scenario for level 1 might be to come up with a label for the release and use this label on every revision that participates. So now every time you want to get the R1 revision for any of these resources, you have to remember the revision name and provide it on each access. That's not so bad though, and is the same thing as remembering a workspace that has checkedout, R1, and latest in its revision selection rule. So far this is a wash. Now say there's an R2 of the project as a whole. Some of the resources changed and some of them didn't. You could label all the participant revisions with R2 and that would work. But, after a while specific revisions might have a lot of labels on them making the revision history of many resource hard to manage. In addition users have to remember something new, use label R2 instead of R1. An alternative is to just label the ones that changed with R2 and put checkedout, R2, R1, and latest in the revision selection rule. Then you'll get the right versions without remembering R1, R2, ..., you only have to remember the same workspace you were using before the revisions changed. All users get updated just by updating their workspace. The default workspace revision selection rule can be changed to so that clients that can't or don't specify a revision will get the right revisions too. You could do this with default labels, but it would take a lot more work to update a property on every resource resetting its default when you can just add a single entry to a revision selection rule. Workspaces just provide flexibility and ease of use for level 1, not any new functionality. I think they make the clients simpler and simplify the user's interaction with the server. So they are useful for level 1 even though there aren't any activities or configurations. "Bruce Cragun" <BCragun.ORM2-1.OREM2@GW.Novell.com> on 02/17/99 03:10:40 PM To: email@example.com, Jim Amsden/Raleigh/IBM cc: firstname.lastname@example.org Subject: RE: Version issues It isn't that workspaces provide unneeded functionality for Level 1. It's just an abstraction that a) isn't in simple versioning models now, so would require learning and understanding, and b) isn't necessary. The way I envision it for a Level 1 implementation is this: 1. If I request a resource and specify nothing other than "get me this resource" the default is to give me the latest. Without branching and other Level 2 features, this is trivial. With Level 2 implementations, this is interpreted as the latest on the main line. 2. If I want something other than the latest, I include a Revision Id or a Label. This works fine for both levels, without any complexity whatsoever. Am I just not getting it? >>> <email@example.com> 02/17/99 11:20AM >>> Comments below in <jra> tags. Chris Kaler <firstname.lastname@example.org> on 02/17/99 12:13:42 PM To: Jim Amsden/Raleigh/IBM cc: Subject: RE: Version issues I don't think level 1 servers want to deal with revision selection rules. I suspect they could be complicated. As well, we need to understand the semantics of parallel checkouts in the "default workspace". The current definition of a workspaces prohibits this and I think it is an important requirement for level 1. <jra> Level 1 revision selection rules don't need to be complicated at all. There are no activities or configurations, so the revision selection rule has checkedout and 0 or more labels. When a resource is accessed with a simple URL, this means, get the checked out revision if any, otherwise look for a revision that has a matchin label. It's hard to imagine anything simpler. </jra> Geoff and I started talking about the Revision-Id header yesterday. I think it is reasonable for a client to request version X of /foo/bar.htm. It seems a cumbersome requirement to have to set the revision of /foo/bar.htm in the default workspace to be X and get /foo/bar.htm. As well, this won't scale at all. Imagine one person trying to get version X and one trying to get version Y. We clearly need more discussion on this, but I don't yet see how we can eliminate a header that specifies a revision. I do believe that we could condense several headers into one... <jra> I also belive that users want to access specific revisions given the label. If they can assign a label, they should be able to access the resource that they assigned the label to. Recall that this capability is in the model. In the new version I moved the method to Repository.getResource(url : String, label : String = null) : Resource. There's also Repository.getResource(url : String, context Workspace) : Resource to access a resource in the context of a workspace. One reason you would want to do this is if you want to look at an old version, or compare two revisions, and don't want to change your workspace. My issue isn't that I didn't want access by labels, only that access when labels aren't specified should use Workspaces to resolve the URL. </jra> I, personally, think that RSR are interesting but probably too complicated for level 1 servers. We could say that the SETDEFAULT method is a "utility" method that modifies the workspace to use the specified revision of the specified resource. This allows us to still describe level 1 functionality in the context of level 2 workspaces. And for level 2, it provides a handy service for augmenting an RSR without having to pull it, modify it, and put it. <jra> Again, I don't think revision selection rules are complicate at all, especially for level 1 which doesn't have activities, merging, or configurations. The complexity results from introducing multiple revisions. Leaving workspaces out of level 1 will just move the complexity to the client or user who have to remember lots of labels on a resource by resource basis. This makes the server simpler, but not WebDAV. I stress again, what would anyone want to do with versioning level 1 that workspaces wouldn't support? What would workspaces include that would be considered too much for level 1? We need specific scenarios that address these issues. As you know, I am also keen to keep things simple. Its just I want the simplicity for the users and clients, not necessarily just for the server. </jra> Thoughts? Chris -----Original Message----- From: email@example.com [mailto:firstname.lastname@example.org] Sent: Tuesday, February 16, 1999 12:56 PM To: Chris Kaler Subject: RE: Version issues But if we keep the Revision-Id header and a SETDEFAULT method, this will conflict with level using a default workspace. I suggest we effectively use default workspaces for level 1. This doesn't mean servers have to implement them, only do something that makes them look like they work. Clients should be able to use level 1 services without being aware of workspaces. If activities and configurations are not in level 1, then the workspace only has to consider revision selection rules that include checkedout, latest, and revision labels. This should be pretty simple. Chris Kaler <email@example.com> on 02/16/99 03:21:30 PM To: Jim Amsden/Raleigh/IBM, firstname.lastname@example.org cc: Subject: RE: Version issues [CK] Comments below... A few issues came up at our last versioning working group meeting: 1. DAV versioning level 1 will still need to be a way of resolving access to versioned resources given just a URL (and not a label). If workspaces aren't supported, level 1 servers will have to provide some other way to resolve URLs to specific revisions, perhaps a default revision for each versioned resource. For level 2 servers that do support workspaces, this would result in two, potentially conflicting ways of performing URL mapping. This is a strong argument for including workspaces in level 1. What would anyone want to do with versioning level 1 that workspaces wouldn't support? What would workspaces include that would be considered too much for level 1? If there are no compelling answers to these questions, we should include workspaces in level 1, including the default workspace. [CK] I suggest we keep the Revision-Id header and the SETDEFAULT method. 2. Deleting a resource must explicitly state that the resource is removed from its parent collection; that is, the collection with which the resource is an internal member. Versioning complicates delete semantics. There are three things we might want to delete: an unversioned or working resource, a revision (and all its descendents?) of a versioned resource, a versioned resource and all its revision history. This must be done in the context of versioned and unversioned collections that contain the resource, or versioned resource as an internal member. The preferred way to do this would be to have add and remove methods on collections to create and delete resources as its the collection that controls the namespace. Unfortunately, DAV doesn't have those semantics, so we will have to find a work-around for versioning. [CK] I expect deleting a working resource to be the same as UNCHECKOUT. [CK] Deleting a versioned resource is up to the store. Some stores might [CK] just delete it. Some might create an "delete" version. I don't think [CK] we want to push a specific model on people. Especially since the [CK] DELETE method is about a resource and in no way describes the [CK] underlying repository actions. Actually, the current WebDAV spec is a little confusing about collections and their members. The current spec indicates collections contain URLs, not resources. But, there is the notion of internal members and referential members, and deleting a collection deletes all its internal members. So the collection behaves like it contains resources, not URLs. This issue will likely get more confusing when we add versioned resources, versioned collections, and multiple revisions. [CK]Your right -- some clarification here would be could. 3. It is not possible to automatically create workspaces or activities for either non-versioning clients, or versioning clients that don't specify them. Default workspaces and/or activities must be used. Creating a new workspace or activity on each request could cause resources that were manipulated in the previous request to disappear. [CK] If we say this is what "logically" happens on a Level 1 server then [CK] OK. But if the server must in fact do this, then I think the cost [CK] is too high since Level 1 clients don't care about this information.