Path: utzoo!attcan!uunet!lll-winken!ames!eos!shelby!polya!maslen
From: maslen@polya.Stanford.EDU (Thomas Maslen)
Newsgroups: comp.software-eng
Subject: Re: Source Code Control
Summary: Sun sells one ("NSE"); it's interesting
Keywords: SCM DSEE NSE Sun
Message-ID: <10147@polya.Stanford.EDU>
Date: 21 Jun 89 07:02:10 GMT
References: <133@tirnan.UUCP> <39400028@m.cs.uiuc.edu>
Sender: Thomas Maslen <maslen@polya.Stanford.EDU>
Reply-To: maslen@polya.Stanford.EDU (Thomas Maslen)
Organization: Stanford University
Lines: 42

In article <39400028@m.cs.uiuc.edu> render@m.cs.uiuc.edu writes:

>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.

Hope this isn't too commercial for this newsgroup, but... are people
also aware of Sun's NSE?  It runs on Suns under (I believe) SunOS 3.5
(and 4.0 Real Soon Now, if not already).  It lets one manipulate
revisions of source trees (not just single source files) and has some
notion of variants for derived files.  Reflecting a difference between
industry and academia, parts of it are implemented in the kernel so
that your favourite binary (editor, compiler, whatever) can work
happily with NSE (no relinking needed).

>Of the approaches to distribution that I've read about, the popular one is 
>the idea of putting all your controlled modules in one place (a server) 
>and accessing them only using controlled checkin/checkout commands.  Depending 
>on the method/system you use, you can exclusively lock modules for update, 
>presumably preventing overlapping modifications.  The problem is that this
>write-locking hoses you if you want multiple mods done simultaneously by 
>different developers.  It hoses you even further if the system prevents any 
>access to a module undergoing update.  My opinion is that the system should 
>allow the users to specify the locking strategy to use, either one checkout 
>at a time or as a system-wide policy.  RCS gives you some flexibility, the
>prototype SCM system I built gives you a little more, and I don't doubt other 
>systems do as well.

One of the interesting decisions made by the NSE folks was to
recognize that exclusive locking is often too restrictive.  Their
model lets you "check out" a revision (which gives you a consistent
snapshot of the system) but can allow others to add revisions in the
meantime.  When you finally go to check yours back in, if changes have
been made in the interim, you go through a (largely automated)
reconciliation/merge process.

Disclaimer:  I spent a very interesting summer in a group at Sun doing
something vaguely related to the NSE, so I'm hardly unbiased.

Thomas Maslen					    maslen@polya.stanford.edu