From: Marko Mäkelä (marko.makela_at_hut.fi)
Date: 2007-01-11 21:20:00
On Thu, Jan 11, 2007 at 06:23:51PM +0100, Spiro Trikaliotis wrote: > CVS can operate on a local filesystem, too. ;) The http server is > "problematic", but IIRC, this is possible, too. Actually, the Subversion over HTTP or HTTPS can be hard to set up, since it requires a special Apache module that implements part of the WebDAV protocol. On the other hand, this can be worth the trouble if you are working in a place that blocks ssh access to the outside. HTTP and HTTPS are usually allowed, at least through a proxy. > Anyway, I would never use it this way. ssh is the only remote access I > trust. Right, I wouldn't ever trust an unencrypted protocol (such as CVS pserver) for non-anonymous access either. If I had to use CVS, I'd pipe it over ssh. Also Subversion and rsync can be piped over ssh. > > If you choose FSFS, it's very nice for doing incremental backups > > (e.g., with rsync <http://rsync.samba.org/> to another hard disk or > > over the network), because commits never modify existing files (unlike > > earlier revision control systems, such as RCS and CVS). > > rsync does a very good job sync'ing CVS repositories, too. But if the transfer is aborted for some reason, you will end up having the remote copy in a severely inconsistent state. In Subversion fsfs, commit writes two new files (properties and tree diffs) and edits one file (the one that points to the most recent revision). Also, in case the file system containing your master repository becomes corrupted for whatever reason, if you do "rsync -n" first to see what needs to be copied, with Subversion fsfs you'll get alerted if you see any changes to old files. With CVS, changes to old files are normal, and you would be less likely to notice this. So, you will have to preserve old backed-up versions of the CVS repository to be sure that nothing is corrupted. > Personally, I do not like binary formats (as SVN uses it) very much, not > to speak about databases. ;) If something goes wrong (mostly user > error), if it is really needed, I can edit the CVS repository by hand - > I have done this more than once, especially when I started using CVS. Me too. With Subversion fsfs, you can just delete the two new files per revision and tweak the third file (it's plain text). > CVS repository is nothing more than some RCS files in directories, and > the RCS file format is very good documented. With SVN, this is not > possible. Right, you cannot edit Subversion repositories on the file level like the ,v files of RCS and CVS, but you can edit them on the tree revision level. There even exists a command for editing tree properties (such as svn:log, the change notes of a revision). But for editing the diffs, you are pretty much limited to deleting the most recent revision(s) and recommitting the changes. Not something that you'd do in a multi-user environment. But then again, editing a RCS or CVS repository by hand is not usually a good idea either. I find it great that Subversion commits are truly atomic. Also, you can rename and remove files and directories without having "Attic" directories appear all over the repository. > I have seen some SVN repository bailout, where everything was lost > (only the backup helped). This was with some 1.0.x version. > Additionally, you might want to read the ChangeLogs for SVN - they are > very interesting. :) I switched from CVS (after almost 10 years of using it) to Subversion in late 2005, so I didn't have to deal with the potential horrors of the original BDB-backed Subversion. I know of one company that has all its documents and source code in a single Subversion fsfs repository, tens if not hundreds of thousands of revisions. And surprisingly, it works for them. Of course, no system is perfect. To get back on topic, I wonder what system Commodore used for managing source code. Perhaps just the version-numbered files of VMS? (I presume they used VAX/VMS at least for some pre-Amiga development. I remember seeing cbmvax.commodore.com on the Usenet.) Marko Message was sent through the cbm-hackers mailing list
Archive generated by hypermail pre-2.1.8.