Re: Re (2): collection version resources

   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