Next message: Ross Wetmore: "Re: BATCH operation [was Re: Comments on draft-ietf-deltav-versioning-08]"
Date: Mon, 25 Sep 2000 16:50:41 -0400 (EDT)
Message-Id: <200009252050.QAA24907@tantalum.atria.com>
From: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
To: ietf-dav-versioning@w3.org
Subject: Re: Sharing version selectors [was Re: Comments on draft-ietf-deltav-versioning-08]
We should probably separate this thread into two parts:
- How can WebDAV support the approach Ross is describing?
- What are the pro's and con's of the approach Ross is describing?
Most of my first response dealt with the pro's and con's of the approach
(specifically focusing on a few con's :-).
In this response, I'll switch to the first question, namely how
would you use WebDAV to support Ross's approach.
From: Ross Wetmore <rwetmore@verticalsky.com>
"Geoffrey M. Clemm" wrote:
> 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.
The BIND method provides this kind of sharing. It is
defined by the WebDAV advanced collection extension:
http://www.ics.uci.edu/pub/ietf/webdav/collection/draft-ietf-webdav-binding-protocol-02.txt
We hope to get this into the draft standard track ASAP (basically,
it's done except for one last editorial pass ... we're still hoping
that Jim Whitehead will take care of that, but I'll probably take
a crack at it if it's not done by the time the versioning has reached
"proposed standard" status.
Note that one problem with BIND functionality is that many interesting
repositories do not support it (or have limitations, like not allowing
multiple bindings to a collection).
One reason we do not require BIND functionality for versioning is that
many (probably most) versioning repositories do not support it in its
general form, so it does not provide a basis for interoperating with
existing repostories (and we believe that this is essential for the
protocol to be adopted).
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.
Without BIND functionality, all resources in one workspace are
distinct from the resources in another workspace. You can of
course get sharing by putting your shared resources in one workspace,
and your non-shared resources in separate team workspaces, and then
update your makefiles or whatever when you change your mind about
what should be shared.
Or you can implement BIND functionality for your server, but then
your clients would only interoperate with other servers that also
provided BIND functionality.
> When you say "add or drop a resource", I believe you mean "change which
> other teams that resource is shared with".
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.
Yes, for that you would need BIND functionality.
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.
Just as a head's up, what happens if you are sharing a resource that
contains some of the change, but have your own copy of a resource that
contains the rest of the change (perhaps you are changing an interface,
and have updated both the provider and users of that interface)?
If you have "live" sharing of one of those resources, but your own copy
of the other, you'll get "part" of the logical change, and your next
compile will break. But I digress ... (:-).
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?
The protocol for tracking these live changes from different perspectives
is very simple (just requires the BIND method). Unfortunately, it doesn't
provide a good way of interoperating with existing versioning repositories,
but that doesn't mean you shouldn't use it for yours, if it's the
model you want to present and you are less concerned with interoperation
with existing repositories.
Cheers,
Geoff