Re: WeDAV Versioning Summary

Geoffrey M. Clemm (gclemm@tantalum.atria.com)
Wed, 14 Apr 1999 22:36:15 -0400 

Date: Wed, 14 Apr 1999 22:36:15 -0400
Message-Id: <9904150236.AA07108@tantalum>
From: "Geoffrey M. Clemm" <gclemm@tantalum.atria.com>
To: sv@crystaliz.com
Cc: jamsden@us.ibm.com, ietf-dav-versioning@w3.org
In-Reply-To: <000701be8679$21e56880$e6ea7392@honeybee> (sv@crystaliz.com)
Subject: Re: WeDAV Versioning Summary

   From: "Sankar Virdhagriswaran" <sv@crystaliz.com>

   You folks a put in a lot of good work and I hope you folks don't get
   frustrated with these questions.

Not a bit!  The easy questions are good because they're easy, and the
hard questions are good because they make us go back and either fix
the design or figure out a way to describe it more clearly.

   Now for some questions and concerns about the current model:

   1. I think workspaces are getting overloaded. In the past, we had talked
   about workspaces as a view on to the underlying data (versions,
   configurations, activities). I was happy with this. Now, it appears that
   workspaces are also the place where merge will happen.

Depends what you mean by "where the merge will happen".  The workspace
is definitely the object that you query for "conflicts".  Since it is
the object that does dynamic version selection, it's really the only object
that could detect and report the presence (and then absence) of conflicts.

For servers that support automatic merging, you can "query" for new
revisions rather than create them by checkout/checkin, but since that
is currently expected/desired by very few clients, we have not put in
any protocol support for it.

   This enforces a workflow model on merge processing.

Not sure what you mean by that.  Could you expand a bit?

   Because of this imposition, we have to
   worry about authority/responsibility implications (e.g., access control,
   role related views, private/public, etc.) on workspaces.

Since the workspace is where you make changes, these issues naturally
arise, but providing a "list conflicts" operation on a workspace does
not change/increase these issues.  The key operation that requires
control is "checkin", and that is independent of merge support.

   Finally, on the
   face of it, it appears to limit the workflow model to a two level
   organization - not a many level nested organization of activities.

I don't see how that could be.  You can have as many workspaces as
you need, and organize them in as many levels as is appropriate
(i.e. development workspaces delivering changes to integration workspaces
delivering changes to testing workspaces delivering changes to release
engineering workspaces ...).  I'll be proposing a couple of workspace
properties that should make this clearer (in fact, I promised them to
Jim Amsden about a month ago ... hopefully I'll get to it as soon as
we have advanced collections bindings nailed down :-).

   2. Are you going to be publishing an object model for this summary as you
   did before? In particular, I am confused about the relationships between
   workspaces, activities, configurations.

Yes, both Jim and I maintain various Rose models, but getting them
into ascii art is always a bit of a hurdle (:-).  I'll try to get
mine current, and make it available in some form.

   For example, the text says that a
   workspace contains 'a current' activity. But, this is not true if the
   workspace is also going to be used for merging.

The "current" activity is the activity that determines what activity
your working resources will be associated with (and therefore, with
what activity the revision resulting from checking it in will be
associated).  This is true whether you are just checking out revisions
for performing a merge, or for any other reason.

The activities that specify existing work that you want to merge are
specified in the revision selection rule.

   At steady state, a workspace
   may contain many activities that are being merged. Am I confused?

Those are the ones in the revision selection rule (and the revision
selection rule can specify as many activities as you need).  So you
can read as many activities as you want, but you can only write to
one activity at a time.

   3. For the above two reasons I would recommend that we separate the notion
   of workspace from the notion of where merge processing is done.  While the
   idea of a 'place where work is performed' is common to both of them, the
   workflow and other implications are different.

Since the only support we provide for merge processing is "add activities to
the revision selection rule" and "ask the workspace for a conflict report",
I don't see how this could be done other than in the context of the workspace
(which is responsible for revision selection).

   4. Also, I would like to see the object model for 'activity'. I am a little
   confused about the semantic model for what an activity is.

An activity is just a set of revisions.  The primary constraint on an
activity is that the revisions of a particular versioned resource
associated with a particular activity must all be on a single line of
descent, so that there is always a unique "latest" revision in that
activity for any versioned-resource.  When an activity is placed in
a revision selection rule of a workspace, that rule selects the latest
revision of a versioned-resource that is associated with that activity.
Some servers will also support a "date" filter on the activity, which
causes the workspace to select "the latest revision before that date"
in the versioned resource.

In order to guarantee those semantics in a distributed environment,
an activity can only be "active" in one workspace at a time.  In order
to simplify revision selection semantics, a revision can only be associated
with a single activity.

That's about it!

Cheers,
Geoff