- From: Geoffrey M. Clemm <geoffrey.clemm@rational.com>
- Date: Tue, 2 Jan 2001 18:10:22 -0500 (EST)
- To: ietf-dav-versioning@w3.org
From: Edgar@EdgarSchwarz.de ... my examples come from software development and perhaps that's a special case which isn't to be solved completely by DELTA-V. Software development is definitely a special case of great interest, so if there are any problems with DeltaV providing an interoperable basis for software configuration management, that needs to be fixed. > If so, then how do I create two resources with a shared history > which exist within the same URL namespace? Are we intending to > say "not allowed"? I'm not sure what you mean by "the same URL namespace" but for a workspace I think it makes sense to allow it. Just some months ago I had the pathological case that I needed two different versions of a file in a software release. I believe that the term "pathological case" is key here. There are cases where exposing two versions in a release does arise, but in practice, these cases tend to be pathological, and the value of supporting this is outweighed by the cost of ambiguous merging behavior. For those (rare) cases when you need to do this, Greg's suggestion should be fine (where you just initialize a new version history with the version that you need to expose in the same workspace). > > My ideal solution would be to allow collection versions, and > > thusly working collections, to contain version resources > > *instead* of version histories. Sorry I'm not sure I understand. What's a "version resource" ? A versioned resource, a version of a resource or a versionable resource ? Just to name some guesses. The second (i.e. it is a version of a version-controlled resource). A version resource is a resource that contains a particular state of a version-controlled resource. It is one of the three kinds of resources introduced by core versioning (version-controlled resources, version resources, and version history resources). We don't use the term "versioned resource" (because it so frequently has been shown to mean different things to different people). We do use the term "versionable resource" (to mean a type of resource that could be put under version control, but is not version-controlled at the moment). > > Activities contain versions, and baselines contain versions, > > which should be all the version containment that you need. I'm not sure I agree. Just imagine what happened a while ago: Somebody came and told me: I want the OSI-Stack of MS14 4.0 for our new project ! So I had a look: MS14 4.0 is version 2.61 (just an example number) which is composed of a couple of thousand of C, include, assembler and other files. In deltav terminology, MS14-4.0 is a "baseline" (which is a special kind of "version" that selects other versions). And it contains OSI-Stack 5.55 which in deltav would be a "subbaseline". (Still a couple of hundred files divided in dozens of directories). So all which is necessary is to merge OSI-Stack 5.55 to the workspace where you are developing your new project. You don't have to search for all includes you need because the release baseline contains containers which structure the whole stuff. So I want a collection version to contain recource versions and collection versions. Using deltav terminology, you want baselines to contain subbaselines, which they do (with the subbaseline-set property). Now just a short description what I would like to be able to do with DELTA-V: Because I model my software for many years in what I called software units. A software unit was mapped to a directory below a base directory which again could contain other software units or individual files. To allow more than one system to use one of those units, I'd recommend putting the shared units "next to" rather than "below" the system that uses them. But that is of course your choice. So this would be my trial translation to WebDAV speak: VersionHistory = collectionVersionHistory | resourceVersionHistory It's also worth identifying "baselineHistory" as a special kind of version history. CollectionVersion = collectionVersionHistory versionName { ResourceVersion | CollectionVersion } What you are calling a "collection version" is what DeltaV calls a "baseline". ResourceVersion = rVH versionName In DeltaV, each version has its own URL, so you don't need a version-history, version-name pair to identify one (just its version-URL is sufficient). But we do support the notion of a version-name, so that's OK. WorkSpace = { ResourceVersion | workingResource | CollectionVersion | workingCollection } A deltav workspace resource is a set of version-controlled (and non-version-controlled) resources. Since you show "PUT" working against a relativePath, it looks like you are supporting server workspaces (not client workspaces), so your workspace would not have workingResource's or workingCollection's (but rather would have checked-out version-controlled resources and checked-out version-controlled collections). Some operations for a workspace: WS.merge(relativePath, VersionHistory, versionName) # populate the workspace In DeltaV, you can apply UPDATE or BASELINE-CONTROL to a collection to populate it, but not MERGE. MERGE is only used to modify existing version-controlled resources (not create new ones). In particular, in DeltaV, a MERGE takes a set of versions (usually from an activity or a baseline), and finds what version-controlled resource in the destination of the MERGE (the collection identified by the request-URL) should be the "merge target" of each version. Note that since the name of the version-controlled resource can be different in the workspace that created the new version and in the workspace that is receiving the merge, the decision of what is the merge target of a version must be based on the version history of that version, which is why only one version-controlled resource in the destination of a MERGE can be for a given version history. WS.checkin(relativePath) WS.checkout(relativePath, VersionHistory, versionName) WS.put(relativePath, data. ("plain" | "delta" versionName)) WS.get(relativePath, ("plain" | "delta" versionName)) If you are going to PUT/GET to the relativepath, then you are supporting server-workspaces (as opposed to client workspaces), which means that the CHECKOUT just takes a relativePath argument, and not a version argument. If you want to change the state of the workspace member (to correspond to some other version) before checking it out, you must first issue an UPDATE request, and then the checkout, e.g.: WS.update(relativePath, VersionHistory, versionName) WS.checkout(relativePath). The delta stuff would be probably be nice for good old 56k modems. Yes I know that this isn't a DELTA-V topic. Even if it's in the name :-) The "delta" form of PUT and GET is compatible with, but orthogonal to the versioning protocol (it's reasonable to want delta PUT/GET even if you're not doing versioning, and vica versa). And if you want to have an additional version of a resource in a workspace just merge it to another (working) collection to avoid a name clash. As above, MERGE does not ever create a new version-controlled resource in the destination (it only updates existing version-controlled resources). You'd need to make a VERSION-CONTROL request to create a new version-controlled resource. But you are not allowed to have two version-controlled resources in the same workspace exposing different versions of the same version history, because that would make the merge target of a MERGE ambiguous. I only hope I made myself clear enough because this description is only part of a bigger picture which also contains e.g. a build concept isn't a concern of DELTA-V. Yes, someday we hope to define interoperable building, but not in the first version of the deltav protocol (:-). Cheers, Geoff
Received on Tuesday, 2 January 2001 18:11:10 UTC