Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!usc!ucsd!helios.ee.lbl.gov!bevb.bev.lbl.gov!biocca
From: biocca@bevb.bev.lbl.gov (Alan Biocca)
Newsgroups: comp.software-eng
Subject: Re: Re: Source Code Control
Message-ID: <2901@helios.ee.lbl.gov>
Date: 28 Jun 89 15:36:52 GMT
References: <133@tirnan.UUCP> <9630003@hpirs.HP.COM>
Sender: usenet@helios.ee.lbl.gov
Reply-To: biocca@bevb.bev.lbl.gov (Alan Biocca)
Organization: Lawrence Berkeley Laboratory, Berkeley
Lines: 120

In article <9630003@hpirs.HP.COM> runyan@hpirs.HP.COM (Mark Runyan) writes:
>>/ maslen@polya.Stanford.EDU (Thomas Maslen) / 12:02 am  Jun 21, 1989 /
>>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.

>If there are any technical papers available to the general public on how
>this reconciliation/merge process is accomplished, I would be extremely
>interested in reading them!  The "need" for exclusive locks exists because
>of the difficulty of merging changes back in (at least, in my experience).
>If NSE solves this problem to handle the merge automatically, I'd like
>to know how its done.  (Of course, it may be a company secret for SUN,
>in which case, I'll not know.  But if SUN wants to make it a paper at
>the next USENIX Workshop on Software Management, I'll be the attentive
>one in the front row... :-)

I attended a presentation at the Sun Users Group West Regional Conference
two days ago by Masahiro Honda, the NSE Engineering Manager for Sun.  I
was in the front row.  The session wasn't very well attended, interestingly
enough.

I have no experience with this product and have heard little about it prior
to this brief exposure, so some errors are likely in the following.

The Sun Network Software Environment is intended to support Programming
in the Many type problems -- many machines, many phases, many tools, many
types of objects, many developers.  It is designed to integrate well with
CASE.  NSE manages sets of objects with many versions and many releases.

The unusual feature of NSE is 'optimistic concurrency control'.  This is
apparently the default and allows multiple developers to acquire the same
module at the same time for parallel development.  It is possible to configure
NSE so this is not allowed, so the 'normal' locking type environment is a
subset of NSE's capability.

They (the developers) have found that allowing parallel development is more
of a gain than not doing so, in spite of the greater problem of reconciliation
of parallel paths.  If management has properly partitioned the developer's
tasks so they aren't working on the same problem they tend to touch different
areas of the same files in ways that don't conflict.  Obviously counter
examples would be easy to construct, but the goal is to allow parallelism
where possible.  I suspect the larger a program gets the less likely it is
that programmers are tripping over each other -- providing they are really
working on unrelated changes.  Controlling edits on a file basis is pretty
arbitrary -- depending on how functions are grouped into files this can
be fine (one function per file) or impossible (one file period).

When a developer attempts to check-in a version that has been checked in since
he checked it out NSE tells him he must 'resolve' first.  He then does a
'resync' to get the changes followed by a 'resolve' to integrate them, and
finally a 'reconcile' to put everything back.

The merge/resolve operation can be handled a number of ways.  NSE provides
a tool (merge-tool?) that will attempt to automatically merge the files
textually.  It has no syntactical understanding of the files and will
successfully complete automatically only if the changes to the two files
are non-overlapping.  Where they overlap a user interface consisting of
three windows and a control panel allows the user to control the process
directly (or select an editor and go completely manual).

Marty's comments indicate that they have found this system to work quite
well in practice.  Toward release time they setup 'slots' for each developer
to reconcile his sections to prevent a developer from needing to resync/merge
more than once during the same reconcile.

He also indicated that Apollo's DSEE was similar but was considerably older
and didn't take advantage of some newer technology, didn't support the NSE
optimistic concurrency control, and didn't support multiple parallel
development (bug fixing on old releases while developing new version).
On this last point (parallel development) there was some confusion, so
I could have read that wrong.  Marty also indicated that NSE was more
extensible to user defined types than DSEE.

NSE does provide for merging of changes to one subtree back to another.
This supports the bringing of bug-fixes from old release support into
the new version development.

I asked him what projects inside Sun are using NSE and he indicated that
most new projects are -- the difficulty of changing in older projects is
of course a major impediment to any new system.  He specifically mentioned
the languages group and several others that are using it now.  He also
said the SunOS group is going to begin using it on their next major rewrite
(coming soon).

NSE uses VCS rather than RCS or SCCS to control versioning of source code.
It has tools to read RCS, SCCS, and makefiles to automatically construct
environments for existing projects to ease a mid-project transition.
It relies heavily on NFS and uses SunPro make which automatically handles
include dependencies without 'make depends', etc.  NSE supports development
for single-source multiple architecture (we know why they need that) called
'variants'.  This produces multiple 'dependent' files from the same source.

A very important feature of NSE is the programmer's environment.  NSE sets
up an environment for the programmer that apparently contains all
the files required for the task at hand.  The files are 'logical' -- not
copies but effectively links -- until changes are made (at which time a
copy is made magically).  There is also a way to 'force' real copies
in the first place in cases where this is desirable (performance, etc).
Creation of these environments by hand is a tedious job -- automation here
would be a big help.

My only complaint about NSE at the moment is the cost.  It's very expensive
to get your feet wet on the first license.  The system is really designed
to be site- or group- licensed and the pricing is not bad there, but for
a small-medium project it is tough to justify, especially when you cannot
setup a working test case.  Perhaps Sun should have a cheap single-user
version for small project/demo use.

Anyone really familiar with NSE please correct/add comments -- I've been
eagerly awaiting some real in-depth info from NSE users and this appears
to be a good forum for it.


Alan K Biocca
Lawrence Berkeley Laboratory
AKBiocca@lbl.gov