info-cvs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Migrating from CVS to RCS


From: Lee Sau Dan
Subject: Re: Migrating from CVS to RCS
Date: 27 Dec 2001 07:58:54 +0100
User-agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7

>>>>> "Kaz" == Kaz Kylheku <address@hidden> writes:

    Kaz> You should tell your team members that because they are
    Kaz> familiar with RCS, they are in a better position than the
    Kaz> average user to learn CVS, not to mention that there is an
    Kaz> excellent migration path for their existing RCS history files
    Kaz> to the CVS repository.  There are tons of users who learn CVS
    Kaz> without the benefit of RCS exposure.

    Kaz> If they are truly familiar with RCS, they should be well
    Kaz> aware of its shortcomings, like poor support for projects
    Kaz> that are scattered through a large directory structure, poor
    Kaz> support for treating an opeation on a set of files as a
    Kaz> single operation, poor support (really no support at all) for
    Kaz> branching and merging, no support for distributed use.

I can't agree more!

One of the  biggest problems with the RCS to CVS  migration, as I have
observed, is that CVS has no file locking.  (Yes, you can "cvs watch",
but...)  Some  of my  team members, when  they started with  CVS, kept
asking me how to lock a file under CVS.  I told them, repeatedly, that
CVS uses a parallel development model, which means merging rather than
locking.  They initially felt uncomfortable with this model.  I had to
persuade them that this model WORKS, as proven by the experience of so
many other CVS-backed s/w development projects all over the world.  (I
actually also  highlighted an advantage  of this: if someone  locked a
file  and forgot to  unlock it,  and then  went on  vacation, then...)

Over time, they  no longer had problem with "not being  able to lock a
file" at all.   There were few instances that a  merge was needed, and
they were surprised at how  well CVS can do the merging automagically.
There were one or two  instances of conflicts, and those were resolved
quickly.   The conflicts  were actually  due to  some  manual mistakes
(copying an  older version of a  file from some  floppy, for example),
not  the  CVS  model.    After  some  simple  explanation,  they  have
understood why  that caused the  problems and could avoid  it forever.
Of course, there  is also something to do  with project management and
commit policy.   Fortunately, my project was not  too complicated, and
we had only a few people (5).  It was easy for me to divide the system
into modules  with clear  boundaries, and let  them work on  their own
subdirectory without having to edit files in others' subdirectories.


    Kaz> If people still want to use RCS after that, they are crazy.

I'm crazy, then.  I use both  RCS and CVS, even on one-man "projects".
I use RCS when  it is just a single-file program, or  a program with a
few  source  files.   I  find  CVS an  overkill  for  such  simplistic
situations.  When  the project  involves subdirectories, I  always use
CVS, for obvious reasons.

Note  that my  "projects"  are not  necessarily program  developments.
Sometimes,  it's  just a  LaTeX  document,  with  fig diagrams  and  a
Makefile   for  them.   Sometimes,   it's  just   an  /etc/initd.conf.
Sometimes, it's  just my plain-text  ASCII telephone list  ~/phone.  I
use RCS or CVS whenever I need to keep a history of the files, so that
I can easily extract an older version easily.

-- 
Lee Sau Dan                     李守敦(Big5)                    address@hidden(HZ) 

E-mail: address@hidden
Home page: http://www.informatik.uni-freiburg.de/~danlee


reply via email to

[Prev in Thread] Current Thread [Next in Thread]