From mboxrd@z Thu Jan 1 00:00:00 1970 From: Lucio De Re To: 9fans@cse.psu.edu Subject: Source version control (Was: [9fans] lucio-) Message-ID: <20020110140747.V12098@cackle.proxima.alt.za> References: <20020109050805.9394F19A70@mail.cse.psu.edu>, <20020109073250.H12098@cackle.proxima.alt.za> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: ; from Bruce Janson on Thu, Jan 10, 2002 at 10:37:55AM +0000 Date: Thu, 10 Jan 2002 14:07:47 +0200 Topicbox-Message-UUID: 3cc55986-eaca-11e9-9e20-41e7f4b1d025 On Thu, Jan 10, 2002 at 10:37:55AM +0000, Bruce Janson wrote: > > dump wins out over the SCCS/RCS/CVS per-application approaches by > including more of the environment: e.g. compiler, system includes. > (In practice, has this been a significant win at the Labs?) > They address two different problem spaces, with solutions appropriate to each. That's my issue all along: is there a generic approach that will satisfy a majority of version control needs, or do there have to be mutually exclusive solutions for a wide range of project types? > Two of the limitations of dump are its coarse granularity and its > arbitrary timing. To eliminate these one could extend dump by > allowing anybody to force (and annotate) a dump snapshot. I hesitate to call the timing arbitrary or, for that matter, coarse, because it reminds me of arguments about the real time nature of computer response: throw enough power at it and you can approximate the ideal as closely as you like. Which in itself raises some interesting considerations. But the automatic nature has both benefits and disadvantages: on the one hand it guarantees that history is retained and on the other it allows the user to abrogate all responsibility for doing so. The real downside is that annotation, which, as mentioned here in connection with the changelog, is extremely useful, becomes an even greater burden for programmers, who are already notorious for disliking the generation of documentation. Naturally, the picture painted above is simplistic, but it covers the most pertinent issues of source control: the retention of as much information as possible. In this category we can also include the labelling of releases and, without the doubt, details of the broader environment in which the change occurred. A last note about the environment, while I think about it: /n/dump provides a pretty good boundary, but certainly too wide to be practical for a distributed programming project (think Linux). In CVS, the boundary may well be too tight (yesterday's problem with CVS and APE is a case in point). At the very minimum, there may be a need to provide a boundary that is more relaxed than the CVS "working directory", alternatively software developers may have to be able to include in the concept of a "workspace" any modules outside of the working directory that have been altered during development and at the very least annotate the history accordingly. The option to provide local copies of the environment with each and every working directory is just too impractical, if not downright insane (yet, ghostscript, ssh and others all include a copy of zlib sources in the source distribution archives). ++L