Roy, The most important issue, IMHO, is that your team communicates enough to do branching and merging.
It sounds from the way the developers referred to the "lock file" that you're considering moving up from Visual SourceSafe. Am I correct on this? The mode of development you're working on will dictate how revision control will work. If you're working on anything involving a Microsoft solution, and using Visual Studio .NET, you're really going to have to work on team communication first, because that bastardization of an IDE changes tens of files behind the scenes and doesn't tell you. You're going to have to keep a master set of project files to do builds if you use a SCM solution other than SourceSafe. Working on anything VS.NET related with a tool other than VSS requires extremely competent development managers to handle the builds and the various quirks that you will encounter. If your team actually can communicate and knows how to use diff utilities, CVS will be fine. If your team works on Oracle, C/C++ outside of .NET, Java, or IDEs that don't hide all the project details, CVS will work really well. If you're in an Oracle and/or UNIX shop, it should fit right in with how those environments expect things to be done. Thank you, Mitch -----Original Message----- From: Roy Morris [mailto:[EMAIL PROTECTED] Sent: Mon 5/2/2005 2:50 PM To: [email protected] Cc: Subject: CVS - Lock File Our company has started to look at CVS as an alternative to our current products. When I suggested using CVS I was told not having a lock file or method of knowing who was working on some code was going to be unmanageable. (and nearly beaten to death, by the developers) Since Openbsd has the OpenCVS project, I thought you all might be the best people to ask about this. Is this really going to be an issue for a handful of developers? Thanks in advance for your comments. Roy Morris CONFIDENTIALITY NOTICE: This electronic message is intended to be viewed only by the individual or entity to whom it is addressed. It may contain information that is privileged, confidential and exempt from disclosure under applicable law. Any dissemination, distribution or copying of this communication is strictly prohibited without our prior permission. If the reader of this message is not the intended recipient, or the employee or agent responsible for delivering the message to the intended recipient, or if you have received this communication in error, please notify us immediately by return e-mail and delete the original message and any copies of it from your computer system.
