Newsgroups: comp.lang.smalltalk
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!oitnews.harvard.edu!purdue!haven.umd.edu!news.umbc.edu!eff!news.duke.edu!news.mathworks.com!newsfeed.internetmci.com!uwm.edu!spool.mu.edu!torn!nott!cunews!dbuck
From: dbuck@superior.carleton.ca (Dave Buck)
Subject: Re: Source code/Repository management
X-Nntp-Posting-Host: superior.carleton.ca
Message-ID: <DKDvJr.28C@cunews.carleton.ca>
Sender: news@cunews.carleton.ca (News Administrator)
Organization: Carleton University, Ottawa, Canada
References: <DKD879.J5L@ritz.mordor.com>
Date: Sat, 30 Dec 1995 05:07:03 GMT
Lines: 50

In article <DKD879.J5L@ritz.mordor.com>,
Jonathan Pletzke <jpletzke@ritz.mordor.com> wrote:
>My opinion is that:
>1. Everything stored should be source code.
>2. A regular re-build of the entire system from source should be done.
>3. Each developer should upgrade to the latest build after it has been tested
>4. Test code should be written for each class and group of classes in the 
>entire system by the class authors, and executed each time before the 
>code is committed to the repository, and after the integration has been done.
>5. Each class and method should be fully commented, including a class 
>method called COMMENT or NOTES that answers a string describing the class 
>and all instance variables, and a method comment in each method that 
>declares public or private, expected return value, and function of the 
>method.
>
>Does anyone do this?

I was mentoring for a project using Smalltalk V/Win32 and source
management was an issue that came up.  Normally, I suggest that they
buy Envy Developer which helps out with issues like this.  this
particular company, however, didn't want to spend the money on Envy
Developer.  In order to manage the source, then, we had to arrange a
system like this:

  - One person is the load-builder.  Their job is to put together a
weekly load.
  - Class ownership was assigned for each class.  The owner was the
only person who could submit changes to that class to the
load-builder.
  - File-outs given to the load-builder were in two parts - the class
definitions in one file and the methods in another.
  - Every Friday morning, each developer had to deliver changes to and
additions to his or her classes to the load-builder.
  - The load builder files in all classes followed by all methods.
  - The image is saved and re-distributed to the other developers.

The process is difficult and the load-build sometimes doesn't run
smoothly.  Ordering of classes is sometimes difficult and sometimes
there are things that need to be executed once the code is filed in.
Envy Developer would have helped out a lot, but in the absense of
Envy, we managed to get by.

David Buck
dbuck@ccs.carleton.ca

_________________________________
| David K. Buck                 |
| dbuck@ccs.carleton.ca         |
| The Object People             |
|_______________________________|
