[ILUG] CVS - cluecheck

[kevin.lyda at itg.ie]

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[0].  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
bandwidth issues.

a good page for dev tool links rests on the wine page:

http://www.winehq.com/dev.html

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.

kevin

[0] 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.