Re (3): collection version resources

Hi Geoff and Greg,
thanks for your detailed replies. BTW, my current printout was 10.11.
I just downloaded 1.13 now.

>    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).
Will be OK in practice but I still don't love it. Because it wouldn't be a
problem in my model.

>    > >    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.
> 
> 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).
My problem was that in the draft 10.11 there is a definition for "version" but
not for "version resource". Also Greg (And you in Chapter 11) was talking
about "collection versions" so I assumed that the equivalent term would be
"resource version" and wondered about "version resource".

In his reply Greg told me the following 
> When we say "resource", we are always referring to collections AND member
> resources.
> Resource := Collection Resource | Member Resource
Perhaps that is in RFC 2518 ? But I didn't find it at the start of DELTA-V.
Perhaps this should be made clear (even if 2518 and 2616 are mentioned).
Because the obvious interpretation of a resource I think is of a
"member resource" (Aka file :-)

>    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".
OK, so I suppose I can do what I want. "subbaselines" didn't exist yet the last
time I read the complete draft. A while ago I admit :-)
But perhaps I can do this also with version controlled collection.
So I still have something to read for the next days :-)

> 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).
There is a definition of "working resource" in 4.1 but I would prefer it
to be in 1.3 (Terms) to get a better overview what's going on.

> 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).
OK, sounds fine.

Another comment to 10.13.
5 is about Server Workspace Option. 5.4.1 gives an example creating a
workspace.
But the examples for CHECKOUT and CHECKIN in look very normal and show
no reference to a workspace. Wouldn't it be better to include the
workspace used in 5.4.1 in them somehow ?

I see that there are some important additions to the draft
since I looked at it closely a couple of months ago (The difference between
client and server side workspaces, subbaselines, ...)
All in all I think I will be able to map my model to a DAV-Server supporting
server workspaces. The only feeling that I have is that it's too complex
and introduces too much unnecessary terms.
But because a lot of stuff is optional now this shouldn't be too big a
problem for implementors.

Neverthess my question is whether it would be possible/useful to give a short
formal definition of DELTA-V concepts somewhere as an EBNF grammer
like I'm trying with my stuff. Please don't look at the semantics but just
the syntax. A small grammer can tell you a lot sometimes where you need a lot
of text to describe it in prose.
I changed it a little bit after reading Geoff's comments, thanks.

The basic idea is that a Unit (system, module, component, .... whatever you want
to call it) consists of items and sub units which are mapped to (member) resources
and collection (resources).

VersionHistory    = collectionVersionHistory | resourceVersionHistory
VersionSelector   = VersionHistory versionName | versionURL 
CollectionVersion = collectionVersionHistory versionName wsRelativePath
	{ ResourceVersion | CollectionVersion }
ResourceVersion   = resourceVersionHistory versionName wsRelativePath
WorkSpace         =
  { ResourceVersion | workingResource | CollectionVersion | workingCollection }

Some operations for a server workspace:
WS.baseline-control(wsRelativePath, VersionSelector)
WS.checkin(wsRelativePath)
WS.update(wsRelativePath, VersionSelector) 
WS.checkout(wsRelativePath)
WS.put(wsRelativePath)
WS.get(wsRelativePath)

Cheers, Edgar

-- 
edgar@edgarschwarz.de                    http://www.edgarschwarz.de
*          DOSenfreie Zone.        Running Native Oberon.         *
Make it as simple as possible, but not simpler.     Albert Einstein

Received on Thursday, 4 January 2001 08:31:40 UTC