Changes between Version 3 and Version 4 of Notes/SubversionAndRCS


Ignore:
Timestamp:
02/08/08 13:54:12 (16 years ago)
Author:
VincentMcIntyre
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Notes/SubversionAndRCS

    v3 v4  
    33MarkCalabretta put together a list of points of difficulty he sees with migrating from RCS.
    44
    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
     51) The one-to-one association between a file and its RCS version   (,v) file is used by the Miriad makefiles to define rules that
    76   keep the plain-text sources up-to-date automatically.  These
    87   rules are used explicitly when rebuilding the system and
     
    1312   is no way to implement these rules in svn.
    1413
    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
     142) There is no equivalent for gmake's inbuilt rule to update the   makefile and no way to implement it short of hacking gmake itself
    1715   because it must work in the absence of any makefile.
    1816
    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.
     173) 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.
    2319
    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.
     204) 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.
    2822
    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.
     235) 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.
    3425
    35 6) Presumably because of global versioning, 'svn log' provides no
    36    indication of the extent of changes made to a file at each
     266) Presumably because of global versioning, 'svn log' provides no   indication of the extent of changes made to a file at each
    3727   revision.  'rlog' does and it's a handy feature that I often use.
    3828
    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.
     297) 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.
    4532
    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
     338) 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
    4834
    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.
     359) 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.
    5336
    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.
     3710) 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.
    5738
    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).
     3911) 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).
    6140
    624112) Where have the defunct RCS version files gone?  I.e. those with a ',x' suffix.
    6342
    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
     4313) 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
    6845   proved invaluable in the past.
    6946
    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.)
     4714) 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.)
    7548
    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.
     4915) 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.
    8351
    8452