Next message: Geoffrey M. Clemm: "Re: BATCH operation [was Re: Comments on draft-ietf-deltav-versioning-08]"
Message-ID: <39CF9409.1C24BC5F@verticalsky.com>
Date: Mon, 25 Sep 2000 14:06:01 -0400
From: Ross Wetmore <rwetmore@verticalsky.com>
To: ietf-dav-versioning@w3.org
Subject: Sharing version selectors [was Re: Comments on draft-ietf-deltav-versioning-08]
Comments embedded below ...
"Geoffrey M. Clemm" wrote:
>
> From: Ross Wetmore <rwetmore@verticalsky.com>
>
> "Geoffrey M. Clemm" wrote:
[...]
> > Section 8
[...]
> > Each workspace has its own set of version selectors (so they don't
> > redirect through a common version selector).
>
> This raises further questions about collaborative sharing of versioned
> resources. Let me try to setup a scenario to illustrate.
>
> If there are three teams sharing a common set of resources, one can
> draw overlapping circles to represent the "workspaces" which define each
> team's conceptual set of interest. In the general case there will be
> resources shared by all, shared by each of the 3 pairs and 3 not-shared.
>
> To support effective sharing, it is not the resources that are shared,
> but rather the changes that are shared. For example, it is not the
> case that I want to see "all changes to foo.html by team-3" or "all
> changes made to bar.html by team-1 and team-4". Instead, I want to
> see certain changes, e.g. "fix dangling references to copyright" from
> team-1 and "add animated titles" from team-3. What resources those
> changes involve are something I cannot (and should not try to) predict.
>
> Capturing logical changes is what "activities" are all about.
Actually, I think it is just the opposite, at least in this scenario. The
condition is that each team sees the headrev version as the live version
with all changes regardless of where they came from, as soon as they are
committed. The goal is not to generate an anarchic (in terms of what gets
selected for different teams) or manual followup merge process. One can
think of the shared elements as "shared libraries" or "shared templates"
which are mandated to be common across the teams.
> Each team may have more than one workspace: headrev (for live changes),
> latest build (a consistent set of resources) and qa-approved (a tested
> set of consistent resources).
>
> Sounds reasonable. Note though that in many scenarios, each team
> would also have a separate "development workspace" for each member of
> the team. This allows a team member to do work without being
> disrupted by changes made by other members of the team.
Fine, but for the moment to keep things simpler, I want to just focus on the
core set of workspaces that define the development environment. I am also
specifically not interested in workspaces that are isolated from changes or
require manual resync.
> Ideally, one would like to consider the
> latest-build and qa-approved sets in each team as workspace versions or
> baselines of each headrev workspace.
>
> Yes, each "latest-build" set would best be represented as a separate
> baseline, and the "qa-approved" set would then be baselines
> that have a "qa-approved" property set on them.
>
> In order for the sets of resources in these baselines to be visible
> (i.e. for running the tests), they would have to be loaded into a
> workspace, though.
>
> For the moment, consider only headrev
> in which all teams automatically share any new versions.
>
> Note that if they are checking out the version selectors, they will
> also automatically share any updates to the checked out version
> selectors. If they are using working resources, then the new versions
> will only be visible when someone performs a SET-TARGET.
Agreed. In this system, if changes are made by checking out a working
resource, then the checkin operation will be a compound operation consisting
of a checkin followed by a version selector update.
> How might the headrev workspaces for each of the 3 teams be setup
> if version selectors cannot be shared? Does this mean that one
> must setup appropriate combinations of 7 sub-workspaces?
>
> As indicated above, I believe that it doesn't make sense to define
> sharing boundaries on a resource basis, but rather on an activity basis.
So the answer is that the current WebDAV model doesn't support sharing
of resources (as defined by this scenario). This is a pretty big hole, no?
> If so, what does this mean
> when a team decides it wants to add or drop a resource from its headrev
> workspace, i.e. will it have to move from one of the sub-workspaces to
> another?
>
> When you say "add or drop a resource", I believe you mean "change which
> other teams that resource is shared with". As indicated above, I don't
> believe that can form an effective basis for sharing. Instead, you
> will want to either "merge a whole baseline" from some team or "merge
> an activity" from some team.
No, I mean add or drop a resource from my headrev workspace. I don't
want to be concerned about who else is using it and have to fix up their
environment.
I don't want to merge activities from another team or have them merge
activities into some global set of workspaces either. I want those changes
to be added by them and become visible in any (live) team workspace.
> This is a reasonably common scenario, but I don't really see how the
> current proposed standard would handle it. What have I missed?
>
> Let me know if my responses above still need clarification (or if you
> disagree with my conclusions on the merit of resource vs. change based
> sharing).
I do not necessarily want to define a standard that is either resource or
change based. Ideally, I would like the standard to be neutral in such
things and let me choose the particular model or environment best suited for
a given situation or implementation. I am unhappy that it seems to be so
difficult, or require so many followup operations and external knowledge to
handle what should be a simple task of tracking live changes to resources from
different perspectives? The client-server networking issues around compound
operations will probably exacerbate any bias builtin to the standard in this
regard :-).
If the only way to track live changes automatically is to reference through
the same version selector and, there is no way for workspaces to share version
selectors, is this not a significant shortcoming. Could version selectors not
point to other version selectors (in another workspace), if sharing them is not
allowed? The situation here would then be solved by defining a global headrev
workspace that all teams reference from their individual subsets. Changes to
either the global or team specific version selectors or workspace properties
would allow for the different perspectives?
[...]
> Cheers,
> Geoff
Cheers,
RossW
=====