-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Rupa Bholanath Lahiri wrote: > As there are many experts in Configuration Management in this group I > ask of this opinion here - 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. 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.
I think that would be a bad idea. If I have a file checked out, it may not be ready to be checked in. Forcing a check-in may actually break the build. > Is there any other way to > ensure that developers have not inadvertently left out checking-in > files which they should have checked-in? You need to train and trust your developers. Automated processes can only take you a limited way. How would you handle new files which were added to the repository? CVS cannot tell whether a file which has not been added to the repository is critical to the build. I'm not sure any configuration management system could. There are ways around this. First of all, train your developers in the cardinal rule of team development: Never Break The Build! The command 'cvs -n -q update' will show a list of files that have not been checked in, and files that have not been added to the repository. Get your developers in the habit of using that command. Scrum, XP and other practices push the concept of continuous integration. Boiled down to its simplest, that means you break your work down into chunks that can be checked in frequently. Other developers in the team refresh their working copies frequently as well. The definition of "frequently" can vary from team to team, but is usually "not more than a few days", and can sometimes be "several times a day". You might also consider setting up a computer dedicated to performing automated builds. There are many tools, such as Cruise Control, which will automatically detect a check-in, refresh a local checkout and start a build. - -- Jim Hyslop Dreampossible: Better software. Simply. http://www.dreampossible.ca Consulting * Mentoring * Training in C/C++ * OOD * SW Development & Practices * Version Management -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqbvdoACgkQLdDyDwyJw+NZLACgsO8OH3egL+O7rVHCrQl/JdzM a8wAoIveqe0GX96+3H0DyESnv0uBIjCH =msXo -----END PGP SIGNATURE-----
