Rupa, > As there are many experts in Configuration Management in this > group I ask of this opinion here -
I think that is a poor idea. This mailing list is for the discussion and support of users of the CVS version control system. It is assumed that you have already: 1) looked at your business requirements and identified specific measurable criteria to determine the success or failure of SCCM in supporting those requirements 2) chosen a SCCM methodology that supports those requirements and 3) determined that the SCCM methodology can be implemented in CVS effectively After you have implemented your SCCM utilising CVS and other tools you should: 4) continuously measure the criteria to determine the rate of success of the SCCM project 5) invest in your open source software by providing documentation, hours of coding and/or financial support for the software 6) upgrading the software to keep with current features 7) continue to study industry best-practice for how SCCM is helping other similar companies A support mailing list is ideal for helping you implement your methodology in CVS, but not at helping you determine the advantages and disadvantages of methodologies that are unimplementable in CVS. And any SCCM oriented mailing list is unsuitable to helping you determine your business goals. A newsgroup more dedicated to generic discussion of SCCM is this one, though like all mailing lists it has it's quirks: http://groups.google.com/group/comp.software.config-mgmt/topics?lnk=srg Note: some members do go on a lot about a web site 'cmcrossroads' - please be aware that 'cmcrossroads' is is by no means objective, just as any one person on this mailing list, or config-mgmt should not be considered objective. > Before doing a build there may be a practice to check all > working copies if there are any files which are modified but > not checked-in. You are right. There may be. There also may not be. If you could tell us about your business objectives, and your SCCM methodology and how this fulfills your objective everyone would have a much easier time assisting you. > So one person may go around checking status of files in each > person's working copy and accordingly check-in files which > are not checked-in. > Is there any other way to ensure that developers have not > inadvertently left out checking-in files which they should > have checked-in? Jim and Bob have both tried to discourage you from this. They have made assumptions about your business obectives and your SCCM methodology and specifically how it supports your business objective. I will not try to make such assumptions and instead take you at your word - you need to do this. Taking this position: Jim's answer that you need to train your workers is also my best answer. We had a similar requirement years ago, for audit compliance and customer billing we needed to have all developers check in their work by COB each Friday. I trained my staff to do this. Of course I trusted them too, but that didn't mean I also didn't measure. I got a report of how much work (lines/files) was checked in for each team member on Friday, and also an 'at' job ran on each PC late Friday night to search for sandboxes and uncommitted files on each PC. On Monday I could 'see' if any team member had not followed procedures and committed all outstanding work. If I suspected a team member of non-compliance I asked them about it, and generally they had either forgotton (and were reprimanded) or had really forgotton (about a piece of work or a particular sandbox) and were given some refresher training on how to run and use the tools. Jim and Bob have also both mentioned continuous integration. I find this hellish. The theory is very good, and indeed our development team use it, but I see it misused more often that used effectively. I believe that to be effective that continuous integration needs to be coupled with promotion or maturity (change management), not checkin (version control). I do not want the benefits of continuous integration to act as a disincentive to commit early and often (which is good for documentation, co-operation, billing, project management, etc). So I encourage commit early and often, and then promote changesets when they are ready to build, and then re-promote as often as necessary. This is why CVSNT, ClearCase, Dimensions, CM Synergy all have support for user defined change sets and merge-by-chageset (which SVN, CVS, Git, VSS do not). So I hope from my comments that you can see that the key to the answers is not command 'x' or tool 'y', but rather an understanding of your business requirements and how your SCCM process is expected to address them. If your business requirement is to improve your billing for hours/lines of code, then your SCCM process needs to facilitate people committing early and often and assigning those commits to customer projects and counting the hours/lines. Remember: SCCM is an overhead. Or to put it more bluntly, SCCM is a cost. The reason why so many people do not like version control is that usually the costs outweight the benefits (Susan Dart previously of the Carnegie Mellon Software Engineering Institute did some studies to document this I believe). CVS may be 'free' but SCCM will cost you - it will cost you every hour of every day. Investing some cold hard time (and probably cash) in good analysis of your business requirements, of SCCM methodologies, project management and finally tools and software will pay off in ensuring that your final system delivers measurable benefits that outweight the costs. Finally - I think that the tool 'Cruise Control' mentioned by Jim is (at least partially) responsible for an enormous amount of wasted time and effort and unsatisfactorily implemented SCCM systems. Why? Because it is implemented poorly (I usually come across it at customer sites 'polling' CVS for changes even 2 or 3 seconds) and does nothing to actively encourage people to think about good or effective SCCM. Regards, Arthur Barrett
