Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to email@example.com.
Patrick, > I agree, Version Control SHOULD be an integral > part of any software project. > > But ... <snip> This is not at all uncommon thinking, however usually stems from previous "bad experiences" of "version control". Preconceptions about what version control is and what its primary and secondary effects are cause many small to medium businesses to make what more informed professionals would describe as "poor decisions". There was a revolution about 10 years ago when "configuration management" replaced "version control". CM is focused on delivering benefits to the business and has as a component "version control". If CM is a directive from "the top" because the directors can see tangible business benefits then it is implemented in the team just like time sheets - because if you don't do it, then you don't get paid. That is fairly draconian - but often how CM gets implemented. The good news is that if it is implemented by people who know what they are doing then it is designed to fit in the company culture and have a positive impact on the satisfaction of the workers who will interract with it daily. The "CM revolution" has been followed with the development of tools and processes that integrate "better" with a developers workflow. And this is the area that this newsgroup is primarily concerned with. CVSNT, TortoiseCVS and related projects are not particularly concerned about implementing some whizz-bang new feature - they are focused on delivering tools that are "enjoyable" to use. You can implement "concurrent" (also known as unreserved) version control without your developers even knowing it's there. It is a great way to get started and begin collecting metrics (things like # of lines changed per developer, most frequently modified programs/modules etc) as well as collecting a history of the changes/evolution of your software. The developers of CVSNT (March Hare Software) can assist, or you can read the many books on CM and CVS or get other help. Today there exists legislation such as SOX that requires that software development companies can audit changes to their code (if they sell to any publicly listed US company), but is not new. Many industries (eg: aeronautics) have had legislation that requires this for many years. So I invite you to stop saying "but" and start asking "how" - "I know I *should* use VC/CM, and I was hoping someone could help me understand *how* can I do that here...". Regards, Arthur Barrett