On Wed, 27 Feb 2002, Tobias Burnus wrote: > Marko Schuetz <[EMAIL PROTECTED]> wrote:
[...] >> >From personal experience I can attest that Aegis is a great tool to >> steer software development... > A revision based system wouldn't be bad, that's true. The problem is > that Hans version needs to be available in this system and frequently > be updated. Otherwise it doesn't make that much a sense. > > Does someone know where the strength of these RCS lay? > - CVS (http://www.cvshome.org/) This is widely used in public projects and, as such, it's easy to find experts. >From experience, it scales to very large projects poorly but, in this context, that's hardly relevant. (no pun intended) It's inability to cope with file moves is a real pain and it's per-file version management makes it difficult to ensure the success or failure of individual actions, especially as the system gets more disributed. It's also insecure, requiring babysitting to ensure sanctity of access at all and, unless SSH remote access used, it's almost impossible to secure well. > - Subversion (http://subversion.tigris.org/) This is slated as a replacement for CVS. It's apparently self hosting but appears to have gotten bogged down in the rush to incorporate XML, WEBDAV, SOAP, .NET or whatever else the buzzword of the week is this week.[1] It's features as a revision control system are, with minor exceptions, identical to CVS. It's far less broadly used and employs vastly more complex technologies, making it a much higher risk target than CVS, in terms of security. > - arch (http://www.regexps.com/#arch) This is very new and claims a lot. It's not well documented nor well matured. It seems to cope reasonably well with file renaming and atomic actions, at least according to it's paperwork and it's author. It's security is questionable, given that a number of exploitable errors were found in the FTP client implementation built into it. It requires a large number of non-standard libraries, totaling around 30,000 to 50,000 lines of C code, regardless of it's advertised 3,000 line count. It's ability to support large scale development has been questioned by a number of people who /do/ make competent source management systems[2]. My personal observations on the system and it's techniques supported most of their claims though I have had next to no practical exposure to the system. > - aegis (http://aegis.sourceforge.net/) Unless I am very much mistaken this is a development process tool that works with your choice of revision control system and imposes additional process on it. Last I checked it talked about RCS, CVS and SCCS, but may support more. This may be a solution to problems of greater scope than revision control, which may actually be the problem you are trying to address here, but it's not, in and of itself, a revision control system. It also implies a lot more formal process than most open source development efforts use which, if you are trying to make the development of ConTeXt, would most likely impede your aim. Of these, CVS is the only tool I would consider using for any sort of distributed or open source development. It's not particularly secure but it's better than the competition. Of those you didn't, BitMover looks interesting but is not free in most senses of the word. PRCS also seems interesting but I have never gotten quite motivated enough to do much about it. It's author has plans for a network protocol but, as of my last check, this had not eventuated. Subversion and arch are *NOT* mature enough that it would be fun to try and use them for a real project, I would suggest. ...and I thought that the research at my last job would never come in handy again. :) Daniel Footnotes: [1] I don't actually know that .NET or SOAP have been added yet but it's not a bad bet to make... [2] The chap who produced PRCS and X-Delta, who's name I cannot bring to mind[3], and Larry McVoy, of BitMover fame. [3] If you care enough I can dig it up. :) -- Documentation is like sex: when it is good, it is very, very good; and when it is bad, it is better than nothing. -- Dick Brandon
