Re: Version issues
Sankar Virdhagriswaran (sv@hunchuen.crystaliz.com)
Mon, 26 Apr 1999 11:21:59 -0400
Message-ID: <009801be8ff8$8a149a60$d0acddcf@crystaliz.com>
From: "Sankar Virdhagriswaran" <sv@hunchuen.crystaliz.com>
To: <dbarrell@opentext.com>, "'Sankar Virdhagriswaran'" <sv@crystaliz.com>,
Cc: "Falkenhainer, Brian" <Brian.Falkenhainer@usa.xerox.com>,
Date: Mon, 26 Apr 1999 11:21:59 -0400
Subject: Re: Version issues
> If this is the consensus, then I agree that versioning should also be
> optional.
>
As far as I can tell (and it is not my role to say this - so take it with a
grain of salt), there seems to be some consensus on two levels for
versioning support. Bruce from Novell had suggested 3 levels, but did not
follow up to some objections raised. So, I am assuming that folks don't mind
2 levels.
> > This is just good design methodology. However, determining levels of a
> > protocol is based (IMHO) more on market and deployment reasons.
>
> If everyone agrees, then let us make this an explicit versioning goal!
>
As Geoff says in another note, they have been trying mightily hard to
achieve this goal. While I still have some issues w.r.to where we are in the
orthogonality dimension, I think I should credit Jim Amsden and Geoff for
making hell of an effort. Perhaps making it into an explicit goal would help
and I would fully support it.
> > can work in the context of DAV. First, there is the question of 'linked
> > object consistency management'.
>
> Is totally orthogonal to what level of versioning (even none) is supported
> by the server.
>
Not in the context of parallel development or in the context of
embedded/linked resources. If I edit an HTML page as part of a set of pages
I am working on and you edit one of the pages linked by that HTML page as
part of another set of pages, what should happen when I submit my changes
and you submit your changes? I am *not* talking about *link management* that
is used to detect dead links. I am talking about maintaing consistency. One
(IMHO, horrible) solution is to lock all the pages linked to a page when I
check out the source of the links. In a pathalogical case, this will
essentially lock the Web site out such that only I can work on it.
In addition, given that HTML pages embed and link include files, code
segments, style sheets, images, objects, etc., maintained in separate files,
I don't see how the simple versioning scenario can work except to lock all
the embedded/linked files such that they don't evolve while I am editing an
HTML page. IMHO, this will essentially ground site development to a halt in
any web site where more than 3 authors are working on that web site.
> Can you give an explicit example? I cannot imagine why not!
>
See above. Does this make sense to you?
> We must be careful not to argue on terms which haven't been properly
> defined. Before I get into this argument about "simple versioning" and
> "proper configuration management", I would like to understand what we are
> actually discussing.
>
Fair enough. Simple versioning to me implies a system like SCCS (from a user
interaction model). When I want to evolve a file, I check it out. The system
locks the file such that nobody else can edit it at the same time. When I
check-in my changes, a new version (revision ?) is created.
Configuration management allows me to identify a group of files (resources
in the HTTP context) as being a consistent unit. I think of each HTML page
(i.e., the most popular HTTP resource) as a configuration for the reasons
given above (embedding and linking, and the need for parallel development).
> This is totally orthogonal. A variant is simply a translation of a
revision
> to some other format (be it language, document format or character set
> encoding etc. etc.). If you view the resources as a tree with the
> "variantable" (whew!!!) nodes as leaves which can sprout at various points
> on the stem, then variants can be viewed as blossoms which sprout from the
> base of a leaf. Some leaves have no blossoms, some have multiple. Variants
> are never versioned. The base variant is versioned (master).
>
But, from an authoring perspective how will the user scenario work.
Typically, (at least in the US of A) while some body is editing a english
page, some body else is editing a french variant of the same page.
Typically, the person editing the english page coordinates their work with
the person editing the french page. Unless these two pages are considered to
be part of a set whose consistency has to be maintained (i.e., a
configuration), the system cannot help resolve potential conflicts that
might arise when one of the authors looks (i.e., reads) the page being
edited by the other author in order to edit their page (and vise versa).
This in my mind results in a requirement for configurations. And, read-write
based conflicts - which I have been pushing for without much success. Even
if we don't do read-write conflicts, at least configurations help me deal
with multi-lingual authroing situations. Maybe there are simpler solutions,
but given the fact that we are dealing with embedded and linked resources
and given that some of these resources have variants that are edited by
multiple people in parallel, I really can't see how simple versioning will
work. My prediction is that with tools that support simple versioning (i.e.,
level 1), the authoring organization will build procedures to implement
'configuration management' suffering through human imposed errors or
serializing the development process losing productivity. But, hey, that is
the market choice!!
> I don't think we should ONLY support "simple versioning", but rather that
> not all versioning functionality is necessary for the majority of servers
> and therefore we need different levels of support. Failure to do this will
> result in many vendors having to provide functionality they do not
actually
> need to provide in order to be WebDAV versioning compliant.
Everybody agrees to multiple levels of versioning. Most of the group (I
believe) believes in only two levels of support (as Geoff points out it is
actually 3 levels, but never mind Geoff's precision !!). Most of the group
also supports your requirement for orthgonality that Geoff addresses in his
other message.
Sankar