Changes between Version 4 and Version 5 of Notes/SubversionAndRCS

Timestamp:

02/08/08 13:54:37 (16 years ago)

Author:

VincentMcIntyre

Comment:

--

Notes/SubversionAndRCS

@@ -4 +4 @@
 
 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.
+   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.
+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.
+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.
+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