From: "James A. Robinson" <jim.robinson@stanford.edu>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] rev control
Date: Tue, 2 Jan 2001 20:28:40 -0800 [thread overview]
Message-ID: <20010103042845.16E9F199E4@mail.cse.psu.edu> (raw)
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>
> 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.
>
next prev parent reply other threads:[~2001-01-03 4:28 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-01-03 3:54 presotto
2001-01-03 4:28 ` James A. Robinson [this message]
2001-01-03 4:31 ` James A. Robinson
2001-01-03 4:31 ` James A. Robinson
2001-01-04 0:31 ` Steve Kilbane
2001-01-04 0:23 ` Steve Kilbane
2001-01-04 11:15 ` Boyd Roberts
2001-01-04 11:16 ` Boyd Roberts
-- strict thread matches above, loose matches on Subject: below --
2001-01-03 2:50 Russ Cox
[not found] <gja@meowing.net>
2001-01-02 17:47 ` greg andruk
2001-01-02 19:30 ` William K. Josephson
2001-01-03 1:33 ` Scott Schwartz
2001-01-04 5:12 ` greg andruk
2001-01-04 10:53 ` Boyd Roberts
[not found] <jim.robinson@Stanford.EDU>
2000-08-20 5:58 ` [9fans] booting problems with 3rd ed James A. Robinson
2000-08-22 0:04 ` James A. Robinson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20010103042845.16E9F199E4@mail.cse.psu.edu \
--to=jim.robinson@stanford.edu \
--cc=9fans@cse.psu.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).