I've been using CVS successfully for some time now to manage a web-based application. I'm to the point where I think I understand (conceptually) CVS. However this means I know what I can do, but not exactly how to do it or IF I should do it.
We now commit our changes using CVS and run a cgi script on the server that updates the checked out copy in the website. However our needs are growing and I'm not sure what the best solution is. Because our application is very complex in nature, we can't simply open the pages in a web browser. They need to be uploaded to a specially configured webserver. Because of this, all of our testing has been done on a live system. This is proving to be a problem as our user base is growing. It is now almost impossible to do any testing without generating calls to customer support. The answer is to install a test server and test there. Here is my proposed solution, please give me your feedback so that I know if I'm on the right track. I imagine all files will continue to reside in the same CVS server. Developers will have the application checked out. When we make a change, we have to note that this change is for our own testing purposes. We may make several commits before we get it right. Once everything is just the way we want it, we have to mark our changes as "need testing". Once testing has been completed, our changed files will be marked as clean and good. Only these clean and good files can be updated on the main webserver. Therefore there are three states to a file, "clean", "need testing", and "working". Changes will happen very frequently. As a matter of fact, it's about all we do during the day. There are over 1,500 files (not counting binary files) in the website spread over a very intricate folder structure. It's very common for a specific task to involve 1-5 files. Sometimes this constitutes all of the files in a folder, other times it doesn't. Here's the idea I have so far. ====TRUNK==CLEAN==================+===== \----TESTING BRANCH------------/ The main trunk will be considered clean. Everything here should be copied over to the webserver. A branch will be created off of this called testing. Once an item has been tested and is known to work, it is merged back into the clean trunk. A test webserver will be set up to keep an entire copy of testing branch available for browsing. What I don't understand is exactly how this is going to work. There is always going to be a TESTING BRANCH that will for the most part, be identical to the TRUNK. All of the FAQ's I've read discuss the difficulties that are involved with repeated merges from a branch and etc. This scares me a little as some of our developers are not very technology savvy. As a matter of fact, I don't think they can even spell CVS. An alternative that I haven't seen documented too much would be to do the opposite as above. The trunk exists as NEEDS TESTING. Once a file has been tested it is moved into a CLEAN branch. The live server could then just keep a checked out copy of the branch. ====TRUNK==TESTING==============+===== \----CLEAN BRANCH------------/ Using your experiences with CVS, can you recommend one of the two solutions or suggest another? Manageability is high on my list of priorities. Also would someone be willing to demonstrate the commands I would use to perform some common tasks? I've got some books and command references that I can use to understand the commands better, but it helps to see what order to do them in and what results to expect. I greatly appreciate any help you can give and the fact that you're taking time to read my e-mail. Matthew Nuzum www.bearfruit.org [EMAIL PROTECTED] _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
