From mboxrd@z Thu Jan  1 00:00:00 1970
From: "James A. Robinson" <jim.robinson@stanford.edu>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] rev control 
In-reply-to: Message from presotto@plan9.bell-labs.com 
   of "Tue, 02 Jan 2001 22:54:16 EST."References: <20010103035425.D50F1199E6@mail.cse.psu.edu> 
 <20010103035425.D50F1199E6@mail.cse.psu.edu> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <17216.978496119.1@aubrey.stanford.edu>
Message-Id: <20010103042845.16E9F199E4@mail.cse.psu.edu>
Date: Tue,  2 Jan 2001 20:28:40 -0800
Topicbox-Message-UUID: 426096c2-eac9-11e9-9e20-41e7f4b1d025

> Russ has a point.  A project with a small group, 10 or less, is
> more easily managed by really communicating than by using a
> program that lets you avoid communicating.  However, to do
> it, you need a group dynamic that works.  There were usually
> 5 of us running around in the same code on Plan 9.  Our
> programming styles eventually synthesized into something that
> we could all tolerate.  We learned when and who to warn when we
> are about to do something, and who to ask when we get in
> trouble.  We got used to fixing each other's mistakes.  It
> got to the point that I'ld make some changes, compile, find
> a few syntax errors, and hear Rob or Phil yell from across
> the room that they were fixing my syntax errors so they could
> finish their own compile.  A text editor that tells you when
> you're about to write back a file that was changed while you
> were editing is a HUGE help.  And of course, that doesn't work
> unless you're also living in a common file system.  It also
> helps that the people are also relatively close by, reachable
> instantly by phone, email, or a loud yell.
> 
> This dynamic takes time to create. I hadn't really
> realized how well we worked together till Sape Mullender
> joined the group.  It's taken months before Sape and
> I can work in the same source without constantly stepping
> on each other's toes even though we're using the same tools
> that worked so well with the rest of us.
> 
> The dump file system was invaluable.  However, its utility
> was not in synchronizing our actions.  It was
> 1) a crutch that gave us a certain fearlessness when attacking
>   code.  We always knew that there was an indelible version
>   from the night before.
> 2) a history of changes that can easily be perused to correlate
>   a code change to a new behavior in the system.
> 
> Source control systems like CVS, SCCS, etc all try to provide
> these two things, i.e., a history of changes and some
> synchronization.  I've worked as a developer on 5 OS's now.
> The worst/biggest was the #5ESS project with millions of lines of
> code and thousands of  programmers.  The project was subdivided
> to compartmentalize the work.  However, it was still not uncommon
> for people that didn't even know of each other's existance to
> be working on the same piece of code.  There wasn't a file system
> big enough to handle everyone so it was necessary to check things
> in and out.  It was also impossible to have an intelligent
> conversation between 2 people wanting to make contradictory
> changes because they were probably each trying to satisfy
> requirements from different parts of the company and each was
> in some way justified.  We needed to branch the code in
> infitesimal ways to satisfy all the intended customers.  NO was
> never an answer since the requirements were usually the result of
> some law passed in the community being delivered to.  No 2 #5ESS's
> have ever been delivered running the same code.  Never the less, we
> have to keep track of all versions of the code that have ever been
> shipped, be able to debug them, and apply the fixes to all versions
> that they may apply to.  This is far beyond the ability of mortals
> not to mention tools.  We had almost as many people working
> on the control tools as the code itself.  The were as many/more people
> adjudicating changes and doing ode reviews as there were people writing
> code.  It was not unusual to take a week to write 25 lines of code
> because of all the controls, testing, checking in and out, and
> code reviews.
> 
> We recently tried a much smaller project, PathStar, and ran into the same
> problem.  Every customer wanted/needed a different set of changes
> to the code.  To control all the branching, we once more had
> to result to a code management system.  The system wasn't really
> needed to synchronize multiple people changing the code for a
> common cause.  There were 100+ programmers and they wrote their
> code on the same Plan 9 file server.  They all pretty much knew
> who the others were that were working on the same code and they
> could use all the mechanisms that we could.  However very few
> of them managed to fall into the same work mode that we did.
> Because of what they were used to they tended to copy the whole
> source tree once a week, work on that, and then check the changes
> back in.
> 
> I'm not sure what the moral is here.  I've always believed it was
> make the project small and get a dozen or less smart peolple to work
> together on it.  However, some problems don't cut up nicely into
> small pieces and it's hard to get a dozen smart people into one
> place so you use CVS or Sablime and deal with the heartache.
>