home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / software / 2909 < prev    next >
Encoding:
Internet Message Format  |  1992-07-21  |  5.8 KB

  1. Xref: sparky comp.software-eng:2909 comp.unix.admin:4246
  2. Path: sparky!uunet!pcad!john
  3. From: john@pcad.UUCP (John Grow)
  4. Newsgroups: comp.software-eng,comp.unix.admin
  5. Subject: RCVS and multiple software development sites (SUMMARY)
  6. Keywords: CVS, RCVS, version control
  7. Message-ID: <614@pcad.UUCP>
  8. Date: 21 Jul 92 18:35:45 GMT
  9. Followup-To: comp.software-eng
  10. Organization: Personal CAD Systems, Westford, MA
  11. Lines: 140
  12.  
  13.  
  14. Most of the responses I received were requests for the
  15. summary.  Apparently this is a problem for many software
  16. development sites.  A summary of the responses I received is
  17. below.
  18.  
  19. I thank everyone who responded to my request and apologize
  20. that I didn't get the summary posted sooner.
  21.  
  22.      -- John
  23.  
  24. My original posting:
  25.  
  26.   I am looking for the software version control software
  27.   package, RCVS to run on Sun and RISC System/6000
  28.   workstations.  My understanding is that this is the CVS
  29.   version control software package with extensions to handle
  30.   multiple development sites.  This software was mentioned
  31.   during the system administration tutorial sessions at the
  32.   USENIX conference last month.
  33.  
  34.   I'm also interested in what others have done to solve this
  35.   problem.  We have three development sites each with a copy
  36.   of our source repository.  Two are connected by a 56K line
  37.   and the third is a single host connected via modem by uucp.
  38.   Basically, I want changes made to one copy to get
  39.   transferred to the other sites' repositories with some
  40.   verification that the updates were successful and that each
  41.   repository is synchronized with each other.  The difficult
  42.   part of this is in resolving a simultaneous update to the
  43.   same file in different release areas ("simultaneous" in this
  44.   case can mean a couple of hours apart if the sites are
  45.   separated by uucp over the phone line).
  46.  
  47.  
  48. Summary:
  49.  
  50. Brian Berliner maintains a CVS mailing list.  if you are
  51. interested in subscribing to it, he can be reached at address:
  52.  
  53.   Brian.Berliner@Central.Sun.com
  54.  
  55.  
  56. From: Jeff Polk <uunet!BSDI.COM!polk>
  57.  
  58.   I am the other author of CVS (with Brian Berliner) and am the person
  59.   working on RCVS.  I have a prototype which mostly works, but which still
  60.   has some major problems.  I'll be going on vacation next week, and I
  61.   hope to get some work done on it while I'm gone.
  62.  
  63.  
  64. From: Peter Costantinidis Jr. <uunet!ossi.com!peterc>
  65.  
  66.   While I was at UniSoft we used a system for keeping different
  67.   development sites in sync with eachother.  We had developers
  68.   in the UK (London) and in California (Emeryville) simultaneously
  69.   modifying, among other things, kernel source code.  We used "uucp"
  70.   to ship the data, though rcp, etc., could be used as well.
  71.  
  72.   I am now with a different company (OSSI), where we hope to
  73.   eventually use the same system for keeping our source in sync
  74.   with a site in San Jose and a couple of sites in Japan.
  75.  
  76.   UniSoft is now selling this as a product, so you should contact
  77.   them to find what's involved in getting it.  Ask about "DV" and
  78.   "Robacom".
  79.  
  80.   The way the system worked was fairly simple:
  81.  
  82.   o incoming changes are applied to local site
  83.   o local site generates its local changes
  84.   o local changes are transmitted to remote sites
  85.  
  86.   The philosophy was that all sites would have identical
  87.   source, ignoring update latency.  That is, assuming that
  88.   no one worked on weekends, on Monday mornings all sites
  89.   would be the same.  On Tuesday and other mornings, they
  90.   are probably not identical due to changes which have not
  91.   yet been generated or applied.  This all assumes different
  92.   timezones.  If everyone was in the same timezone, then it
  93.   is quite likely that each morning all sites would be in sync.
  94.  
  95.   If your communication mechanism was cheap, you could get by
  96.   with updates being transmitted hourly.  Since ours was a long
  97.   distance phone call to Europe, we only called twice a day.
  98.  
  99.  
  100. From: uunet!mailrus!uflorida!qtp.ufl.edu!bernhold
  101.  
  102.   I have not heard of "RCVS".
  103.  
  104.   Somewhere in the most recent GNU CVS distribution (1.3, I think) it was
  105.   mentioned that additions to facilitate remote development were planned
  106.   (short term, it sounded like).  Maybe you are actually referring to a
  107.   new version of CVS (possibly not yet released)?
  108.  
  109.   The originator of CVS, Dick Grune, continues to develop a version
  110.   implemented as shell scripts.  The GNU version uses the same ideas but
  111.   codes them in C and adds some fancier logging, etc. than the scripts
  112.   do.  I believe Grune's CVS is now somewhat ahead of GNU CVS as far as
  113.   features go.  I think this version can be had from
  114.   star.cs.vu.nl:dick/cvs.  I don't know anything about it, but it seems
  115.   that it might be relevant.
  116.  
  117.  
  118. From: Kimmo Suominen <uunet!lut.fi!Kimmo.Suominen>
  119.  
  120.   I am also interested in multi-site version control.  I would really
  121.   like to hear how others do it.
  122.  
  123.   I am now using RCS on two sites and manually transfer changes over to
  124.   the main repository.  I am myself using a private repository, which I
  125.   destroy every now and then when I have completed work for a release.
  126.   For minor changes I just lock the file in the main repository without
  127.   copying the whole RCS tree.
  128.  
  129.   This is all very tedious, and I would love to hear about an automated
  130.   system that would work over UUCP as well.
  131.  
  132.  
  133. From: uunet!informatik.rwth-aachen.de!steinbr (Michael Steinbrunn)
  134.  
  135.   we are currently running into the same problem of organising
  136.   distributed software development. I've already considered
  137.   writing a couple of shell scripts that utilise the ordinary
  138.   email service in order help us keeping the sources
  139.   consistent. But if there exists a package that already does
  140.   this, I would like to try it first. I've queried archie
  141.   without avail; if you receive any information, could you
  142.   drop me a line? Thank you very much in advance.
  143.  
  144.  
  145.  
  146.  
  147.  
  148. -- 
  149. John Grow (System Administrator, P-CAD/CADAM Boston R&D Office)
  150. Personal CAD Systems/CADAM  |   uucp: uunet!pcad!johng
  151. 1 Technology Park Drive     |
  152. Westford, MA 01886          |
  153.