Thanks so much to everyone who responded to my query about
NSE. I got a fair number of responses, and decided just to include them here:
>From amdcad!cayman!randyd@ames.arc.nasa.gov Tue Feb 13 18:02:17 1990
To: kam@titan.tsd.arlut.utexas.edu
Subject: Sun's NSE
Status: RO
Hi!
We reviewed NSE about 1.5 years ago. At that time, we decided against it.
The reasons were:
1. The disk overhead for the virtual file systems was excessive
2. The view that each user gets to the sources promotes change
conflicts.
3. Change conflicts still need to be resolved manually.
4. Binaries were not handled at all. We would be left to write
our own binary handlers.
5. Moving source files into and out of NSE is awkward. We do
that alot.
6. It looked like a premature product. It may be better now.
We liked the dual-window tool for resolving change conflicts.
The impression I am giving is more negative than the impression I had
at the time. Perhaps there were other features that we did not need or
appreciate.
-=- Randy Devol
>From rfinch@water.ca.gov Tue Feb 13 20:41:02 1990
X-Mailer: Mail User's Shell (7.0.3 12/22/89)
To: Katherine Minister Hosch <kam@titan.tsd.arlut.utexas.edu>
Subject: Re: Sun's NSE?
Status: RO
I asked about this same thing on sunspots sometime ago...following are the
responses I got. I finally decided on RCS, which is working quite
well with a Gnu Emacs interface.
Date: Tue, 25 Apr 89 12:02:57 CDT
From: ucdavis!ucbvax!Central.Sun.COM!sunloop!oconnor!porsche!miker (Mike Raffety)
Message-Id: <8904251702.AA28800@porsche>
To: ucdavis!caldwr!rfinch@Central.Berkeley.EDU
Subject: Re: SCCS vs. NSE
Status: OR
We evaluated NSE a few months back, and found it a relatively immature
product, but with promise. We've been using a fairly elaborate SCCS
system for a couple of years ago of my own design; it's currently
supporting thousands of programs and source files, a total of about a
million lines of source code. It's also supporting multiple archi-
tectures. Attached is a potpourri of standard documents I have about
it for our new programmers ... cut at the long line of dashes, and most
of them run through nroff.
[remainder deleted]
From: ucdavis!ucbvax!proteon.com!jas (John A. Shriver)
Message-Id: <8904251840.AA03336@monk.proteon.com>
To: ucdavis!caldwr!rfinch
In-Reply-To: Ralph Finch's message of 4 Apr 89 17:01:38 GMT
Subject: SCCS vs. NSE
Status: OR
SCCS and NSE are different orders of magnitude. I have never used
NSE, but have used SCCS and RCS. RCS (readily available as source, on
4.3bsd tape) is much easier to use than SCCS, and may have more
capabilities. RCS handles errors very gracefully. The internals of
RCS are quite ratty (coding style), but work. SCCS has the advantage
of universal availability. DEC's Ultrix Engineering Group used to use
RCS, but switched to SCCS.
NSE is "motherhood and apple pie". It replaces SCCS, supersedes the
sunpro Make, etc. If you like the sunpro Make, that is an example of
the style of NSE.
NSE is almost absolutely screen based. There is very little that you
can do via a TTY interface. Could make working from home a real lose
without a Sun at home.
Anything like NSE (which is really a CASE tool) requires a lot of
setup.
From: ucdavis!ucbvax!stout.UCAR.EDU!vanandel (Joe Van Andel)
Message-Id: <8904261547.AA04101@stout.UCAR.EDU>
Received: by stout.UCAR.EDU (4.0/1.00.UUCP-MOD.8-11-85)
id AA04101; Wed, 26 Apr 89 09:47:48 MDT
To: ucdavis!caldwr!rfinch
Subject: Re: SCCS vs. NSE
Newsgroups: comp.sys.sun
In-Reply-To: <474@caldwr.UUCP>
Organization: Field Observing Facility, NCAR, Boulder, CO
Reply-To: ucdavis!ucbvax!ncar.UCAR.EDU!vanandel
Status: OR
It depends on what your budget is, and what you want. SCCS simply
provides a simple source code code control that allows you to retrieve
old versions of source. You have to provide your own mechanism or
convention to record the proper versions of each module that went into
a release. For my money, 'Revision Control System' RCS, provides the
same functionality, and has a cleaner interface for mere mortals.
Having used both SCCS and RCS, I would definitely use RCS. I even use
RCS for simple, one person development. RCS is publically available
(it used to be on the user contributed software tape packaged with 4.2
BSD). Here's some info from the manual page:
From: ucdavis!ucbvax!uunet.UU.NET!jvc!jonathan (Jonathan Hue)
Message-Id: <8904262235.AA28206@jvc.uucp>
To: uunet!ucbvax.berkeley.edu!ucdavis!caldwr!rfinch@uunet.UU.NET
Subject: Re: SCCS vs. NSE
In-Reply-To: your article <474@caldwr.UUCP>
News-Path: uunet!cs.utexas.edu!tut.cis.ohio-state.edu!mailrus!cornell!uw-beaver!rice!sun-spots-request
Status: OR
> Currently we do not use any type of source code system to control edits,
> etc. As we build up our network of Suns, and as more engineers get on the
> system, we want to begin using some method.
Sounds like this place, before I got here. Also sounds like this place next
week, since I'm leaving.
I like RCS. I've used SCCS and like RCS better. I like it mainly because
it's easier to use, and I like the commands. A couple months ago someone
wrote about RCS and SCCS in UNIX Review magazine and said it was a tossup on
small to medium sized projects, but liked SCCS for larger projects because
it was more robust and was easier to do software releases with.
But like I said, I really like RCS's commands. I can send you a copy if you
like, it's not PD, but if you register with the author you can use it.
-Jonathan
From: Don Wells <ucdavis!ucbvax!nrao.edu!dwells>
Message-Id: <8905112106.AA15885@fits.CV.NRAO.EDU>
To: ucdavis!caldwr!rfinch%ucbvax.berkeley.edu@uvaarpa.virginia.edu
Subject: re- "SCCS vs. NSE"
Cc: dwells@fits.cv.nrao.edu
Status: ORr
Due to a mailer screwup, this message got stuck in a queue ffor
days and days. Sorry about that. -Don.
----- Begin Forwarded Message -----
Date: Tue, 25 Apr 89 12:07:26 EDT
From: dwells@fits.CV.NRAO.EDU (Don Wells)
To: ucdavis!caldwr!rfinch@ucbvax.berkeley.edu
Subject: re- "SCCS vs. NSE"
Cc: dwells
ralph,
I just read your query in Spots V7n249.
I have NSE on order. I have studied its manuals closely, and got
Sun people to come in and give us a presentation. I also attended
the NSE session, led by the NSE development team, at the Miami SUG
last December.
The overall concept of NSE is *much* more far-reaching than that
of SCCS, although superficially they do the same job. Even if
we restrict our interest to version control NSE has some special
advantages. The mechanism for resolving differences can be used
to help diverging versions contrinue to track devleopment of
underlying code in the "main" version, as well as to resolve
concurrent changes to the main version.
Shipment of NSE for 4.x has been delayed for months now,
and recetnly when I inquired they would not quote me a date,
although SMI did say that the product recently went inot beta test.
My guess is that we will get it by late June or early July.
I would be very interested to hear your views of these products
and related issues.
Regards,
Donald C. Wells, Associate Scientist | NSFnet: dwells@nrao.edu [192.33.115.2]
National Radio Astronomy Observatory | SPAN: NRAO::DWELLS [6654::]
Edgemont Road | BITnet: DWELLS@NRAO
Charlottesville, VA 22903-2475 USA | UUCP: ...!uunet!nrao.edu!dwells
+1-804-296-0277 (38:02.2N/78:31.1W) | TWX=510-587-5482, Fax=804-296-0278
-- Ralph Finch 916-445-0088 rfinch@water.ca.gov ...ucbvax!ucdavis!caldwr!rfinch>From rfinch@water.ca.gov Wed Feb 14 18:00:21 1990 X-Mailer: Mail User's Shell (7.0.3 12/22/89) To: kam@titan.tsd.arlut.utexas.edu (Katherine Minister Hosch) Subject: Re: Sun's NSE? Status: O
Since you are using Gnu Emacs, you might be interested in the interface we're working on. Briefly, I took an rcs.el file from Chris Siebenmann (cks@white.toronto.edu) and added some tag files features. About 1/2 completed is a feature that automatically creates branches for users and checks out those branches. This allows unimformed users to pretty much do their edits independently of each other (we have engineers coming from a DOS environment so they are not used to cooperating too much). Later the RCS administrator can merge users' changes into the main stem.
-- Ralph Finch 916-445-0088 rfinch@water.ca.gov ...ucbvax!ucdavis!caldwr!rfinch
>From yamada-sun!eric@nosun.West.Sun.COM Wed Feb 14 23:25:04 1990 To: nosun!titan.tsd.arlut.utexas.edu!kam@nosun.West.Sun.COM Subject: Sun's NSE? Status: O
If you're interested in mere hearsay, a few months ago our local Sun Users' Group talked about it. As I recall, the consensus was that it's vastly complicated, and pretty much requires that at least one person attend a more-than-one-day seminar to learn how to use it; and that it's still somewhat buggy. Also, that even with those problems, it was a worthwhile product. ------------------------------------------------------------------------- |Eric Hanchrow yamada-sun!eric@nosun.west.sun.com | |Phase III Logic, Inc. ...!{tektronix, sun}!nosun!yamada-sun!eric | |1600 N.W. 167th Place Beaverton, OR 97006 | |Voice: (503)-645-0313 Fax: (503)-645-0207 as of 13-Dec-89 | ------------------------------------------------------------------------ >From contel0!king!maxz@philabs.philips.com Sat Feb 17 19:37:51 1990 To: kam@titan.tsd.arlut.utexas.edu Cc: king!maxwell@uunet.UU.NET Subject: Re: Sun's NSE? Status: RO
We are planning to use it, infact I will be installing it on a homgenous Sun-3 server, a 3/260 for the Sun-3 target this week. We have a person just to be the build/NSE administrator, who we sent to Sun's NSE traing course. I installed 1.2 in Dec. and did some demoing of the product but we have not been using it for production yet.
I'll keep you posted if you wish..
+ Mark
-------------- itzzall4phun- uunet!philabs!contel0!maxz Contel IPC , Stamford CT or contel0!maxz@philabs.philips.com
>From sabourin@sol.med.ge.com Mon Feb 19 20:01:56 1990 To: titan.tsd.arlut.utexas.edu!kam@crdgw1.ge.com Subject: Sun's NSE Cc: blc@sol.crd.ge.com
Katherine,
I have been working with the NSE for a little more than a year. Although I have been frustrated with it on a few occasions, it's operation has been pretty solid. It is difficult to explain some of the pros and cons of NSE without knowing how much you know already. NSE is fairly complicated and has it's own jargon. I suspect that is why you don't see a lot about it in sunspots when people ask for a summary of their impressions about NSE. Needless to say there is a fairly long learning curve for users.
Some of our users don't like the idea of parallel development at all (I know, it's not NSE's problem). The fact that someone else can check out and edit the same file in their private environment really bothers them. It does, however, force them to talk to each other more, and NSE has a great utility for merging a file that two people have modified. They would prefer that NSE would allow them to be notified when this occurs, but at this time the notification facility in NSE isn't sophisticated enought to do this at the file level.
NSE works really well with projects that can be compiled and linked on the sun. It is especially easy to create an NSE environment from an existing product organized with Makefiles and SCCS directories. We also have an environment that performs remote compiles on an HP workstation. That implementation wasn't clean, but it is for a real-time product development project and we are currently forced to use the HP compilers so that we may use their emulators.
NSE can be wasteful with your disk space. The symbolic links in NSE aren't quite the same as you are familiar with, and if you create an environment using these (instead of the copy option) your child environment can be extremely small compared to the disk usage in the parent's version. As soon as you change a file, however, you then have your own history in the vcs (version control system) for that file and even though you might wish to revert back to a symbolic link after you reconcile (put your changes back into the parent environment). The only way I know to do this is to delete and then re-create your child environment (this also assumes that you don't wish to keep a lot of history in the developer's environment). Although the garbage collection facility does help some, child environments can get several times bigger that they were originally (4 to 5 times bigger from my experience so far), but I don't know that any other configuration management scheme would be more frugal.
My Sun support for NSE has been great lately. The people that have been answering my calls are knowledgeable enough about NSE that they can handle my problems while I am on the phone with them without having to do a lot of research and then calling me back. The times they did have to get back with me were still relatively quick.
I hope this helps, but it would probably be more efficient to find out how much you know about NSE and what specific questions you have so that I could give you the information you desire.
Tom Sabourin uunet!crdgw1!gemed!sabourint GE Medical Systems sun!sunbrew!gemed!sabourint Mail Code W-642 (414)-548-5129 P.O. Box 414 Milwaukee, WI 53201
>From sabourin@sol.med.ge.com Tue Feb 20 13:18:06 1990 To: titan.tsd.arlut.utexas.edu!kam@crdgw1.ge.com Subject: Sun's NSE
We are currently using two environments, one is just about at the end of its life cycle and the other is just starting out (as you will be able to tell from their sizes). The information you wanted about these is: avg. size of lines of developer's Environment |size in Mb |true source |#source files |#developers |environments ------------+-----------+------------+--------------+------------+------------- xap | 125 | 187,000 | 1019 | 8 | 15 Mb recon | 10 | 2,500 | 31 | 5 | 3 Mb
When I was in NSE class, I got a lot of information from a guy who said that he had over a million lines of code in their NSE environment, so I think that disk space is where your limitations will be.
As far as using gnu emacs, we have been using that with NSE from the start. The menu driven interface for NSE (called nsebrowse) can be set up to use emacs as your editor. I've found, however, that although the mouse driven interface is nice while you are learning NSE, most people wind up using the command line interface, which also supports emacs.
My only concern about your project is your Ada compiler. (I'm not familiar with Ada). You should check with Verdix? to see if they implemented the NSE hooks in the compiler (i.e. if Ada has include files, the compiler needs to let Make know about the include files during compile so that it can track these as dependency relationships). Otherwise, if you still want to use NSE, you'll have to write your own "preprocessor" to let Make know about these dependencies. (This isn't too bad, I had to do this for the case of remote compiling on the HP machine).
Tom Sabourin uunet!crdgw1!gemed!sabourint GE Medical Systems sun!sunbrew!gemed!sabourint Mail Code W-642 (414)-548-5129 P.O. Box 414 Milwaukee, WI 53201
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:05:56 CDT