Notes/SubversionAndRCS
MarkCalabretta? put together a list of points of difficulty he sees with migrating from RCS.
1) The one-to-one association between a file and its RCS version (,v) file is used by the Miriad makefiles to define rules that keep the plain-text sources up-to-date automatically. These rules are used explicitly when rebuilding the system and implicitly in the dependency analysis. For example, an included header file (.h) is checked out automatically if necessary, even if it resides in a different directory, simply by appearing as a dependency of the target. Without a one-to-one association, there is no way to implement these rules in svn.
2) There is no equivalent for gmake's inbuilt rule to update the makefile and no way to implement it short of hacking gmake itself because it must work in the absence of any makefile.
3) Per-file versioning in RCS has been replaced by global versioning in svn which, for Miriad, involves a loss of historical information. In contrast, the effect of global versioning is available in RCS via the '-d' option specifying a date.
4) Version dates for revisions 0.0 to 1.0 in the svn repository are incorrect, apparently because svn and/or cvs2svn appear to require that increasing global version numbers correspond to increasing times. RCS does not have this limitation.
5) Lack of per-file versioning will make it inconvenient to perform the common task of determining at what revision a particular change to a source file was made. Currently I do a binary chop on the RCS version number for the file, but with svn, changes to a file are tagged with non-consecutive global version numbers.
6) Presumably because of global versioning, 'svn log' provides no indication of the extent of changes made to a file at each revision. 'rlog' does and it's a handy feature that I often use.
7) In svn, $Id$ tags must be enabled explicitly for each individual file that needs it. Bizarrely, svn allows this to be set up automatically via auto-props in config files on a per-user or per-host basis, but not for the repository itself. This means that manual intervention is required on a per-file, per-user, or per-host basis.
8) The $Id$ tags are not replaced in source files visible on the web site e.g. http://svn.atnf.csiro.au/miriad/trunk/prog/clean.for
9) Currently the Miriad RCS repository co-resides with Miriad in the same directory tree and the whole lot can easily be propagated via rsync. In contrast, with svn they are separated, on different machines even.
10) It's not possible to provide third-parties with a copy of the RCS version files as is now done from the ftp area. E.g. Peter Teuben uses them to track my changes.
11) In the same vein, the Miriad RCS repository is currently cached at the observatories (and on my computer at home) and revision history can be consulted even if the link is down (or non-existent).
12) Where have the defunct RCS version files gone? I.e. those with a ',x' suffix.
13) svn's internal format is undocumented and inscrutible. In contrast, RCS's version information is stored in a well-defined and well-documented format ('man rcsfile'). It is readily understandable and amenable to external manipulation and that has proved invaluable in the past.
14) I am particularly concerned that version information stored in svn's internal format will not be transferable to another revision control system should that ever prove desirable - remember how "wonderful" CVS used to be when it was the latest shiny pebble? (But at least CVS is based on the RCS version format.)
15) Ownership of the Miriad repository has been transferred from mirmgr to www-data and presumably so will administration of the repository. This places an extra, unwanted layer of bureaucracy between me and the work I have to do. (Alternatively, I'm quite happy to let you have it all back!) For example, Malte was away on Tuesday so I had to wait till Wednesday to have an svn account created. Also, it wouldn't let me do a checkout anonymously.
See also Notes/Subversion
