Changes between Version 3 and Version 4 of Notes/SubversionAndRCS
- Timestamp:
- 02/08/08 13:54:12 (16 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Notes/SubversionAndRCS
v3 v4 3 3 MarkCalabretta put together a list of points of difficulty he sees with migrating from RCS. 4 4 5 1) The one-to-one association between a file and its RCS version 6 (,v) file is used by the Miriad makefiles to define rules that 5 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 7 6 keep the plain-text sources up-to-date automatically. These 8 7 rules are used explicitly when rebuilding the system and … … 13 12 is no way to implement these rules in svn. 14 13 15 2) There is no equivalent for gmake's inbuilt rule to update the 16 makefile and no way to implement it short of hacking gmake itself 14 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 17 15 because it must work in the absence of any makefile. 18 16 19 3) Per-file versioning in RCS has been replaced by global versioning 20 in svn which, for Miriad, involves a loss of historical information. 21 In contrast, the effect of global versioning is available in RCS via 22 the '-d' option specifying a date. 17 3) Per-file versioning in RCS has been replaced by global versioning in svn which, for Miriad, involves a loss of historical information. 18 In contrast, the effect of global versioning is available in RCS via the '-d' option specifying a date. 23 19 24 4) Version dates for revisions 0.0 to 1.0 in the svn repository are 25 incorrect, apparently because svn and/or cvs2svn appear to require 26 that increasing global version numbers correspond to increasing 27 times. RCS does not have this limitation. 20 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 21 that increasing global version numbers correspond to increasing times. RCS does not have this limitation. 28 22 29 5) Lack of per-file versioning will make it inconvenient to perform 30 the common task of determining at what revision a particular change 31 to a source file was made. Currently I do a binary chop on the RCS 32 version number for the file, but with svn, changes to a file are 33 tagged with non-consecutive global version numbers. 23 5) Lack of per-file versioning will make it inconvenient to perform the common task of determining at what revision a particular change 24 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. 34 25 35 6) Presumably because of global versioning, 'svn log' provides no 36 indication of the extent of changes made to a file at each 26 6) Presumably because of global versioning, 'svn log' provides no indication of the extent of changes made to a file at each 37 27 revision. 'rlog' does and it's a handy feature that I often use. 38 28 39 7) In svn, $Id$ tags must be enabled explicitly for each individual 40 file that needs it. Bizarrely, svn allows this to be set up 41 automatically via auto-props in config files on a per-user or 42 per-host basis, but not for the repository itself. This means 43 that manual intervention is required on a per-file, per-user, or 44 per-host basis. 29 7) In svn, $Id$ tags must be enabled explicitly for each individual file that needs it. Bizarrely, svn allows this to be set up 30 automatically via auto-props in config files on a per-user or per-host basis, but not for the repository itself. This means 31 that manual intervention is required on a per-file, per-user, or per-host basis. 45 32 46 8) The $Id$ tags are not replaced in source files visible on the web 47 site e.g. http://svn.atnf.csiro.au/miriad/trunk/prog/clean.for 33 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 48 34 49 9) Currently the Miriad RCS repository co-resides with Miriad in the 50 same directory tree and the whole lot can easily be propagated via 51 rsync. In contrast, with svn they are separated, on different 52 machines even. 35 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. 53 36 54 10) It's not possible to provide third-parties with a copy of the RCS 55 version files as is now done from the ftp area. E.g. Peter Teuben 56 uses them to track my changes. 37 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. 57 38 58 11) In the same vein, the Miriad RCS repository is currently cached at 59 the observatories (and on my computer at home) and revision history 60 can be consulted even if the link is down (or non-existent). 39 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). 61 40 62 41 12) Where have the defunct RCS version files gone? I.e. those with a ',x' suffix. 63 42 64 13) svn's internal format is undocumented and inscrutible. In 65 contrast, RCS's version information is stored in a well-defined 66 and well-documented format ('man rcsfile'). It is readily 67 understandable and amenable to external manipulation and that has 43 13) svn's internal format is undocumented and inscrutible. In contrast, RCS's version information is stored in a well-defined 44 and well-documented format ('man rcsfile'). It is readily understandable and amenable to external manipulation and that has 68 45 proved invaluable in the past. 69 46 70 14) I am particularly concerned that version information stored in 71 svn's internal format will not be transferable to another revision 72 control system should that ever prove desirable - remember how 73 "wonderful" CVS used to be when it was the latest shiny pebble? 74 (But at least CVS is based on the RCS version format.) 47 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.) 75 48 76 15) Ownership of the Miriad repository has been transferred from 77 mirmgr to www-data and presumably so will administration of the 78 repository. This places an extra, unwanted layer of bureaucracy 79 between me and the work I have to do. (Alternatively, I'm quite 80 happy to let you have it all back!) For example, Malte was away 81 on Tuesday so I had to wait till Wednesday to have an svn account 82 created. Also, it wouldn't let me do a checkout anonymously. 49 15) Ownership of the Miriad repository has been transferred from mirmgr to www-data and presumably so will administration of the 50 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. 83 51 84 52