Tools Committee Meeting submitted by: 12/8/95 Alan Jonckheere Present: Chih-hao Huang, Don Petravick, Ruth Pordes, Fritz Bartlett, Pushpa Bhat, Stu Fuess, John Hobbs, Alan Jonckheere, Stan Krzywdzinski, Qizhong Li-Demarteau, Lee Lueking, Laura Paterno, Serban Protopopescu and Harrison Prosper (on telephone line) Presentation by SDSS (Sloan Sky Survey), in two parts. *** questions and comments from the audience (summarized as per my notes) *** and some minimal interpretations, and drawing parallels to VMS for *** those of us not familiar with Unix are marked by "***" below. ---------------------- Part 1 -------------------------------------------- Don Petravick gave an overview of their code management system followed by a presentation of CVS in particular. The SDSS code management system is: Function Tool Source Code Archive CVS Distribution UPR Verification audit Define Platforms Standards Dependencies Diagram (UPS) Defined Source Code Text Standard files .ANSI-C .Perl .tcl .more *** He didn't really discuss any of these. When asked he did say that UPS *** stores dependencies that UPD reads, but that UPD doesn't actually do *** any dependency checking. I don't think they do much dependency *** checking, it's hard. In principle they could. The hooks seem to exist *** to do so. We don't have anything like this dependency list, but should. CVS -Free (no license hassles) -No (well minimal...) underpinnings required so it's portable. Run on IRIX, Linux, Digital Unix, SunOS. -Three years of experience, they are happy -Scope 21688 ",v" files 1Gb of managed areas 513 machine/uid pairs 55 distinct computers 46 distinct users -Pretty easy to administer -Source Code Backup ("trusted" backups done at FNAL) -Change Control: only certain people can change a module -Distribution: didn't discuss how -Control locus: "is a feature used?" -Management: track who and how many are working on a module, supports concurrency *** Comments: I'd like to talk to him about their code distribution, *** validation and standards control. He didn't say much about those. *** But did make some good points about trying to keep track of *** dependencies which are then stored in UPS but not really used by it. *** (?? I'm not really clear on this, I think that's what he said) ---------------------- Part 2 -------------------------------------------- Chih-hao Huang then gave a more detail presentation on CVS itself. - What do we ask of a source code management system? Safe place for source code Track revisions - Single-user environment vs Multi-user consistency and integrity - Two philosophies/approaches to management Prevention of problems Detection and Recovery to problems *** this is in reference to incompatible changes to code Prevention: SCCS, RCS, CMS allow only one programmer to check out for modification disadvantage programmers must get "in line" dead lock situation Detection and Recovery CVS no locks for checking out work on copy, not original only matters when checking code back *** His inclusion of CMS in the "prevention only" category is in error. CMS *** allows both modes. D0 has specifically chosen to use the prevention *** technique for the library itself because of the difficulty of detecting *** incompatibilities. It's not clear if CVS does a better job of conflict *** detection than does CMS. This needs to be tested. CVS Features Concurrent access and conflict resolution *** conflict resolution seems to be only on the lines which were changed by *** both people. Doesn't handle logical conflicts. They seem to use *** "programmer cooperation" and after release verification to handle these *** conflicts, as do we. The archive doesn't help with this part of the *** problem. *** There was much discussion of what and how conflict detection is done. *** Since we (D0) deliberately disable this feature in CMS, we need to *** understand its operation in CVS and decide if we can live with it. Tracking 3rd party/vender source distributions with local mods *** just another form of concurrent access conflict resolution. Using it *** here probably doesn't have as many pitfalls as it does when used in *** other contexts. location independent module database *** don't know what this means, no one asked. configurable logging support: hooks for executable scripts/applications for logging and notification. *** could be useful, could use for standards checking? symbolic tagging for releases: relieve the burden from Makefile *** equivalent of CMS class? generate "patch" files between releases *** not discussed enough, I, for one don't understand it. May be the most *** useful feature of CVS. Remote Capability: Originally provided by rCVS. Since V1.5 CVS has it built in. Location is transparent to users. Server is "rsh", so needs no system privs. Problems: Generic config requires an account on the server machine. User owns everything he/she puts in the repository. With an account on that machine, one can bypass CVS. *** CMS can have same problems, but we've never had a problem with it. SDSSCVS "fix": use pseudo account for server cvs remote command is rsh-ed to that user name everything owned by pseudo account runs non-standard login shell *** sounds like a VMS captive account ******** Comments by AMJ after the fact. CVS doesn't sound very different than CMS in it's features and capabilities. If it's true that CVS doesn't allow non-concurrent reservations (check-out) we need to consider if we can live with that. After the meeting: John Hobbs tells me that he uses rvs (?) (underlies CVS) and that it has absolute locking (CMS /noconcurrent equivalent). He would be surprised if CVS didn't have it too. So all this discussion is, probably, irrelevant. We just need to decide what we want to do. There are a couple of nice features that CVS supports; remote usage (with the caveats about ownership etc), updating local repositories (that I'm not real sure about), built in hooks for various functions etc. At first glance it looks like a viable replacement for CMS. But it seems that that's about all it would do. It would replace but not improve. The question of concurrent checkout/reservations needs to be studied.