Concurrent development works great most of the time since: 1. The chances of multiple people modifying the same file at the same time is rare. 2. The chances of multiple people modifying the same place in the same file at the same time is rare. 3. Logical conflicts are handled via communication. "cvs edit", "cvs watch" and family afford a good means of communication. When setup properly, CVS will notify those already editing the file. Note that this notification may be too late for some. There exists a "cvs edit -c" patch that'll check for other editors before allowing the edit. The check can be overridden via "cvs edit -f". Note also that this patch may prevent "cvs edit" from working if the server connection is down (IMHO, "cvs edit -c" should fail if the server connection is down, but "cvs edit" and "cvs edit -f" should work). Noel Enc (See attached file: edit-c.diff) [EMAIL PROTECTED] on 2000.03.31 19:23:29 To: [EMAIL PROTECTED] cc: (bcc: Noel L Yap) Subject: Reserved vs. non-reserved checkout I'm sure that this topic has been covered here before, so if someone wants to point me to a transcript of this issue, feel free. Let me preface, first, with the following comments. I understand that the loosely coordinated, widely distributed development associated with open source projects has a variety of demands that differ from internal, "closed" development projects. My experience is primarily in the latter scenario. I further this (possibly religious) discussion because I want to be enlightened as to the value and advantage of the unreserved checkout scheme promoted by CVS. And to see if those advantages are really appropriate for the closed development projects. I have worked in closed environments for a long time using reserved checkout systems such as MKS, PVCS, and SourceSafe. In this environment, where many people may be working on the same set of files, and often same file; where there are common programming disciplines and guidelines, I have found the reserved checkout scheme more reliable than merging. Merging, in my experience, by developers of a variety of skill levels has allowed hard to find bugs to creep in when conflicts are manually resolved or not detected. We allow simultaneous modification of files, but this was the exception. And branching projects allowed us to maintain older versions of projects while new development continued along the main "trunk." Comments? Bill...
|
I’m
sure that this topic has been covered here before, so if someone wants to point
me to a transcript of this issue, feel free. Let
me preface, first, with the following comments. I understand that the loosely
coordinated, widely distributed development associated with open source
projects has a variety of demands that differ from internal, "closed"
development projects. My experience is primarily in the latter scenario. I
further this (possibly religious) discussion because I want to be enlightened
as to the value and advantage of the unreserved checkout scheme promoted by
CVS. And to see if those advantages are really appropriate for the closed
development projects. I
have worked in closed environments for a long time using reserved checkout
systems such as MKS, PVCS, and SourceSafe. In this environment, where many
people may be working on the same set of files, and often same file; where
there are common programming disciplines and guidelines, I have found the
reserved checkout scheme more reliable than merging. Merging, in my experience,
by developers of a variety of skill levels has allowed hard to find bugs to
creep in when conflicts are manually resolved or not detected. We
allow simultaneous modification of files, but this was the exception. And
branching projects allowed us to maintain older versions of projects while new
development continued along the main "trunk." Comments? Bill… |
|
|
edit-c.diff