>>>>> "Kaz" == Kaz Kylheku <[EMAIL PROTECTED]> 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 §ő¦u´°(Big5) ~{@nJX6X~}(HZ)
E-mail: [EMAIL PROTECTED]
Home page: http://www.informatik.uni-freiburg.de/~danlee
_______________________________________________
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
