From mboxrd@z Thu Jan 1 00:00:00 1970 From: presotto@plan9.bell-labs.com To: 9fans@cse.psu.edu Subject: Re: [9fans] rev control MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Message-Id: <20010103035425.D50F1199E6@mail.cse.psu.edu> Date: Tue, 2 Jan 2001 22:54:16 -0500 Topicbox-Message-UUID: 4259f8bc-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.