[ILUG] CVS - cluecheck
kevin.lyda at itg.ie
kevin.lyda at itg.ie
Thu Mar 2 11:31:20 GMT 2000
some goofy comments have been going on about cvs and i think some people
need some severe beating with a cluestick here.
cvs was *designed* for multiple remote sites. it's built on top of
rcs which was oriented towards single site dev, and cvs dev was done so
specifically to gain remote access.
the cvs documentation explains why locking is done as it says so i suggest
reading it. regardless cvs can be configured for traditional locking
if it floats your boat.
cvs is used for a slew of free software projects and does so quite
effectively. wine, freebsd, mozilla, etc. caolan has mentioned
bandwidth issues in the past, and while there are some tools to alleviate
(compression, cvsup, etc - the freebsd handbook has a page on keeping
up to date: http://www.freebsd.org/handbook/synching.html) that i think
it's still one of the only valid issues. but i think he's comparing it
to downloading patch files - clearcase isn't anywhere close to solving
a good page for dev tool links rests on the wine page:
there are a number of nice front ends - tkcvs is especially nice for
doing merges. because cvs has a number of flame inducing issues floating
around people will often just look at those and dismiss it. locking is one
issue, and afaik (cvsup which can be used to update trees in a more bandwidth
friendly manner) is written in modula-3 which can be difficult to build.
to make some of the comments that have been made in view of many successful
cvs using projects (like freebsd) is, well, silly.
 Reserved and unreserved checkouts each have pros and cons. Let it
be said that a lot of this is a matter of opinion or what works given
different groups' working styles, but here is a brief description of some
of the issues. There are many ways to organize a team of developers. CVS
does not try to enforce a certain organization. It is a tool that can
be used in several ways.
Reserved checkouts can be very counter-productive. If two persons
want to edit different parts of a file, there may be no reason to
prevent either of them from doing so. Also, it is common for someone
to take out a lock on a file, because they are planning to edit it,
but then forget to release the lock.
People, especially people who are familiar with reserved checkouts,
often wonder how often conflicts occur if unreserved checkouts are
used, and how difficult they are to resolve. The experience with
many groups is that they occur rarely and usually are relatively
straightforward to resolve.
The rarity of serious conflicts may be surprising, until one realizes
that they occur only when two developers disagree on the proper design
for a given section of code; such a disagreement suggests that the
team has not been communicating properly in the first place. In order
to collaborate under any source management regimen, developers must
agree on the general design of the system; given this agreement,
overlapping changes are usually straightforward to merge.
In some cases unreserved checkouts are clearly inappropriate. If
no merge tool exists for the kind of file you are managing (for
example word processor files or files edited by Computer Aided Design
programs), and it is not desirable to change to a program which uses
a mergeable data format, then resolving conflicts is going to be
unpleasant enough that you generally will be better off to simply
avoid the conflicts instead, by using reserved checkouts.
The watches features described above in section Mechanisms to track
who is editing files can be considered to be an intermediate model
between reserved checkouts and unreserved checkouts. When you go to
edit a file, it is possible to find out who else is editing it. And
rather than having the system simply forbid both people editing the
file, it can tell you what the situation is and let you figure out
whether it is a problem in that particular case or not. Therefore,
for some groups it can be considered the best of both the reserved
checkout and unreserved checkout worlds.
More information about the ILUG