Re (2): collection version resources

Hi all,
there are interesting discussions at the moment. I'm not sure I understand all the
terms you are using. So please be tolerant if I ask some dumb questions.
Also my examples come from software development and perhaps that's a special case
which isn't to be solved completely by DELTA-V.

> 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. BTW it wasn't a
problem with the model I will describe later.


> >    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.

> > No need for this change.  Activities contain versions, and baselines
> > contain versions, which should be all the version containment that
> > you need.
> I can go with that.
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. And it contains
OSI-Stack 5.55 (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.

> > You are about to get lost in a maze of twisty passages, all of which
> > look alike ... don't go there (:-).
As long as you are able to kill the thief you can find your way out :-)
Just drop some of the stuff in your inventory once in a while.

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. So this would be my trial
translation to WebDAV speak:

VersionHistory    = collectionVersionHistory | resourceVersionHistory
CollectionVersion =
  collectionVersionHistory versionName { ResourceVersion | CollectionVersion }
ResourceVersion   = rVH versionName
WorkSpace         =
  { ResourceVersion | workingResource | CollectionVersion | workingCollection }

Some operations for a workspace:
WS.merge(relativePath, VersionHistory, versionName) # populate the workspace
WS.checkin(relativePath)
WS.checkout(relativePath, VersionHistory, versionName)
WS.put(relativePath, data. ("plain" | "delta" versionName))
WS.get(relativePath, ("plain" | "delta" versionName))
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 :-)

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.

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.

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 Tuesday, 2 January 2001 17:08:46 UTC