You are using an invalid email address:  [EMAIL PROTECTED] which is resolving to someone who does not wish to get this mail.  Please take this address out of your mailing lists.

Regards,
Ruth Ann Hill
TI Central Help Desk , Team Lead           
Email: [EMAIL PROTECTED]
972-575-4071 or pgr 972-648-4548
You can reach the CHD at:
972-575-4357  or  1-800-527-4740     
Please visit our website @ http://www1.itg.ti.com/help



-----Original Message-----
From: Noel L Yap [mailto:[EMAIL PROTECTED]]
Sent: Monday, April 03, 2000 8:15 AM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: Reserved vs. non-reserved checkout


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...

Reply via email to