(cvs.info.gz) Choosing a model

 
 10.7 Choosing between reserved or unreserved checkouts
 ======================================================
 
 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  Watches 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 watches can be
 considered the best of both the reserved checkout and unreserved
 checkout worlds.
 
    As of CVS client and server versions 1.12.10, you may also enable
 advisory locks by putting `edit -c' and `commit -c' in all developers'
 `.cvsrc' files.  After this is done, `cvs edit' will fail if there are
 any other editors, and `cvs commit' will fail if the committer has not
 registered to edit the file via `cvs edit'.  This is most effective in
 conjunction with files checked out read-only by default, which may be
 enabled by turning on watches in the repository or by putting `cvs -r'
 in all `.cvsrc' files.
Info Catalog
(cvs.info.gz) Watches
(cvs.info.gz) Multiple developers
automatically generated byinfo2html