Re: Build management with Delta-V
ÿ (infonuovo@email.com)
Thu, 12 Aug 1999 09:33:57 -0700
From: <infonuovo@email.com>
To: "'Geoffrey Clemm'" <geoffrey.clemm@rational.com>,
Cc: "Alan Babich (E-mail)" <ABabich@filenet.com>,
Date: Thu, 12 Aug 1999 09:33:57 -0700
Message-ID: <000201bee4e0$ad382e20$0100007f@conclave>
In-Reply-To: <015a01bee441$b4bc7790$0d1b15ac@aftershock.atria.com>
Subject: RE: Build management with Delta-V
%To: Geoffrey Clemm
Delta-V Working Group
%Cc: DMA CSDocs Subcommittee
%From: Dennis E. Hamilton
%Re: Build Management with Delta-V - separation from versioning
Geoffrey,
I support the idea of derivation and building being separated from
versioning. I also notice that there are some cool interdependencies to
deal with. (I just slapped my forehead and said "ahah!") Here's what I
make of it:
DERIVATION VERSUS VERSIONING: NEAR ORTHOGONALITY
Oddly enough, abstracted models of compound/structured documents (e.g.,
where the component dependency might well be some sort of derivation
dependency) are closer to build cases and fit nearly-orthogonally to
versioning as well. The DMA CSDocs model is abstracted enough to have room
for this, although I hadn't looked at this particular case very closely.
[To test ideas of the orthogonality with versioning, I do a lot of thought
experiments on how I manage my documentation and web projects using a
software CM system (viz., VSS). I just hadn't doubled-checked and confirmed
that the abstraction holds up for build management. It does.]
An interesting versioning interdependency comes up in both the
compound-document and the build-management views though -- the desire for
structures that track the latest version in the dependencies. In DMA, the
"pure" dependency model is among revisions, and doesn't float or track in
any way. That is so for a lot of reasons, and we though that we only needed
to specify that in the DMA 1.0 model. [In effect, dependencies are always
"pinned" and the standardized globally-unique references to DMA 1.0
documents are always references to versions. Getting the latest version
depends on additional protocol, as in making queries. We don't
automatically point to an abstracted resource and expect to get the latest
one. This looks simply like a dual of Delta-V, as I understand it, since
there is a straightforward way to get from one view to the other.]
In exploring different requirements checklists from folks, a common theme is
in having ability to form a dependency structure in which the latest
versions of the components are understood. Our conclusion is that both
forms of dependency ("pinned" and "floating") need to be available and
people need the ability to say what they want for a particular dependency
structure. We are adding the "floating" dependency relationship as a
consequence of the compound/structured-documents work. It doesn't change
the abstract versioning model beyond ensuring that the implied
beneath-the-covers interactions occur and referential integrity holds up.
INTERESTING INTERACTIONS: DERIVATIONS AND VERSIONS
Here's what I notice out of this:
1. In dependency structures, in a versioned world, it is important to be
able to represent specific derivations based on the specific versions that
went into the creation of the composite result. This is where there is
audibility, repeatability, etc., as required in rigorous document management
regimes. The same principles apply to electronic documents as to software.
The parallels are pretty clear. (I haven't checked ISO 9000 requirements,
but I would expect that this level of rigor and certainty is mandated.)
2. In practical settings, including what people do in building software
releases using CM software and interactive development environments, one
wants to establish a structure which is an abstraction -- or scheme -- for
making a derivation based on the latest versions of (stipulated) components.
This is a common request, and it is so much how developers approach systems
that it would appear that this is the critical case, rather than a
highly-productive tool atop a more fundamental management requirement.
3. One could use a common object/data model for the relationships employed
in (1) and (2), and we are taking that approach with DMA CSDocs. Then, what
happens when a structure of form (2) is manifested to have a concrete result
at someone's request? If this is meant to be a committed action, and
versions are kept for those, then somehow a new structure of type (1) needs
to be made in consequence, reflecting the actual instantiation that
occurred. That is, a new instance of the derivative object needs to be
established somehow, so that it is auditable, reproducible, etc. Presumably
the floating structure is intact.
So, it is important to be able to locate the static cases from the floating
structure, at least well enough to be able to tell if the current floating
structure determines an existing static structure (i.e., the thing is
already built).
4. Are there any published object/data models that account for all of (1-3)?
When work gets done in this area, the nuances of (3) need to be covered, it
seems to me. I wonder if a new method is required for getting a current
static version of a floating derivation structure. I think checkout or
get-version operations would be badly overloaded if we made them cover this
case.
Oh, I guess "Build" would be it, huh? Duhhh.
Something that is as useful in working with compound documents as it is in
working with software structures. Hmm, that simplifies a lot of places in
compound document work, including controlling how variant renditions show
up. Son-of-a-gun.
-- Dennis
Dennis E. Hamilton
- - - - - - - - - - - - - - - -
mailto:infonuovo@email.com
tel. +1(650)938.4584
fax. +1(650)567.9846
http://www.infonuovo.com
-----Original Message-----
From: ietf-dav-versioning-request@w3.org
[mailto:ietf-dav-versioning-request@w3.org]On Behalf Of Geoffrey Clemm
Sent: Wednesday, 11 August 1999 14:37
To: ietf-dav-versioning@w3.org
Subject: Re: Build managment with Delta-V
Build management (and I agree that it is better called
"derived resource management") is certainly a topic near and dear
to both my company (see: ClearMake) and me personally (see: Odin).
I believe though, that the issues of derived resource management can be
dealt with relatively orthogonally to versioned resource management
(assuming one is suitably careful in how one defines versioning
support :-).
One preliminary way of being "careful" is to reserve the term
"derived resource" for those resources that are mechanically
computed from other resources (commonly called "source
resources").
So although I will eagerly volunteer to participate in any work
in this area, I would not advocate this work taking place as
part of the versioning work.
[ . . . ]
[end]