Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!cs.utexas.edu!uunet!mcvax!unido!tub!coma!andy
From: andy@coma.UUCP (Andreas Lampen)
Newsgroups: comp.software-eng
Subject: Re: Source Code Control
Summary: Distributed identification of source objects vs.
	 Distrubuted system building
Message-ID: <408@coma.UUCP>
Date: 23 Jun 89 13:33:33 GMT
References: <133@tirnan.UUCP> <39400028@m.cs.uiuc.edu>
Organization: Technical University of Berlin, Germany (West)
Lines: 77

In article <39400028@m.cs.uiuc.edu>, render@m.cs.uiuc.edu writes:
> ... Just to make things clear, I am in no way connected
> with the Shape people and have only just gotten their software. 

I confirm that, I am one of the developers of SHAPE =:-) .

> To me it seems that the problems of distributed SCM are similar to the 
> problems of distributed databases, i.e. distributed data and concurrent
> updates.  I know of non-DB SCM systems which attempt to solve this, among
> them Apollo's DSEE (which unfortunately requires Apollo hardware and OS 
> support to work) and DVSS, a distributed version server for CAD applications.

The retrieval of SCM specific data from remote machines in a network
is only one part of the problem "distributed SCM".
When focusing on the aspect of identifying and building configurations
within SCM systems, we have to discuss at least two different aspects of
distribution:
	- distributed identification of source components and
	- distributed system building.

The first point is conceptually quite uncritical. I agree that this
is mainly a technical problem that has basically been solved yet.
BTW, SHAPE's approach to use NFS in order provide network support
was a pragmatic decision (due to lack of time) and I think it works
quite reasonable. Hal is right when he writes that there still are
some problems but most of them will be solved in the near future.
Nevertheless I would like to introduce an own network service but
we have many other plans with higher priority.

The second point (distributed system building) is much more
complicated.  It sounds simple to say "I have a lot of modules to be
compiled and linked together, so I construct single compile jobs, spread them 
all
over my network, gather the results, and link the whole stuff together".
This is what eg. DSEE and some "make"oids do. But this works only in
a homogeneous environment of only APOLLOs or only SUN3s or only VAXes.
Even then you get in trouble when the software environment (eg.
/usr/include) is different on different machines in your network. DSEE
solves this problem by copying not only the source file that is to be
compiled but also *all* other files needed for the compilation to the
compiling machine.

With a mechanism like this you are totally lost in a heterogeneous
environment. For example our network at TU Berlin consists of
a large number of SUN3s, several VAXes (running BSD 4.3, Ultrix,
and VMS), an IBM mainframe, some HP machines running HP/UX and and and.
In our discussion on the problem of distributed system building in a
heterogeneous network we came up with the concept of
'compatibility classes'. A 'compatibility class' would
typically comprise a set properties that define a notion of
'compatibility' for binaries. All machines in a network that are equivalent
in terms of these properties should then be assigned one (or more ?) such
class(es).  Significant parameters include: machine type, operating system
(-version), compiler version, object file format, file system
environment... .

But this is still no *general* solution for managing distributed system
building. For example we will have to provide different levels
of (binary-) compatibility: in our case, VAX/43BSD and VAX/Ultrix are
compatible on object-file level but (sometimes!) incompatible on
executable level (different run time systems). What influence will
dynamic loading have ? How should cross compilers be managed ?

I'll come up with an answer to these questions next week =:-).

Andy

-----

P.S.:   For people interested in a technical discussion on SHAPE I
	recommend to subscribe to our brand new mailing list on SHAPE.
	Send you subscription request to "shape@coma.uucp" or
	"shape@db0tui62.bitnet". 

-- 
Andreas Lampen, TU Berlin
UUCP:   andy@coma (unido!coma!andy)
BITNET: andy@db0tui62