Re: Version issues
Dylan Barrell (dbarrell@opentext.com)
Fri, 23 Apr 1999 11:05:18 +0200
Message-ID: <01BE8D79.2C99AAA0.dbarrell@opentext.com>
From: Dylan Barrell <dbarrell@opentext.com>
To: "'ejw@ics.uci.edu'" <ejw@ics.uci.edu>,
Cc: "Falkenhainer, Brian" <Brian.Falkenhainer@usa.xerox.com>,
Date: Fri, 23 Apr 1999 11:05:18 +0200
Subject: RE: Version issues
The problem with the space for which we are creating a standard is that it
is a space which is dominated by lots of niche products. i.e. there are
different sets of requirements which are considered "minimal" depending on
the end users (SCCS, PDM, DocMan, Content Managament etc.). There are
different configuration requirements for a source code control system such
as MKS Source Integrity as there are for a general web site tool such as
Site Server. It is arguable whether both products should have some
configuration support in order to be useful to their users.
Confining my comments purely to the goals document I think it is desirable
to have orthogonality of support of various "areas" (for lack of a better
word). The areas in question are
Versioned resources
Configurations
Activities
Workspaces
And within the individual areas (most) there should be 2 levels of support
- "minimal" and "advanced".
Nobody can argue that minimal versioned resource support does not include
branches and parallel development. At the same time it must be possible to
manipulate these versioned resources without any support for activities. It
should be possible to have workspaces without support for either activities
or configurations and there is definitely value in configurations without
activities or workspaces. Minimal configuration support certainly doesn't
include automatic inheritance and conflict queues and one could go on.
The only absolute requirement is that the minimum requirements for
versioned resources are met as most of the other areas (with the exception
of activities) are meaningless without versioned resources.
Cheers
Dylan
On Thursday, April 22, 1999 6:40 PM, Jim Whitehead [SMTP:ejw@ics.uci.edu]
wrote:
>
> > I would like to see the levels split even more than that. I believe
that
> > some of the configuration management functionality can be considered
> > "minimal" in order to be useful and the rest should be optional.
> >
> > Has this forum had a detailed discussion on the levels of the
versioning
> > protocol? If not I think the time has come.
>
> So, the problem with just adding another level is that each level
> exponentially adds to the possible client/server interactions. With two
> levels, you need to consider level 1 client vs level 1 server, level 1
> client vs. level 2 server, level 2 client vs level 1 server, and level 2
> client vs level 2 server. With three levels, there are now 9 possible
> permutations, not just four.
>
> The other difficulty is developing a configuration management layer where
> the abstractions are so easily separable that a third layer can easily be
> defined.
>
> Did you have any thoughts on what features should be in this minimal
> configuration management layer, and which features should be excluded?
Or
> was this just a general concern that the design might be getting too
> complex?
>
> - Jim