Just to repeat some of the arguments for CVS that Geoff told me: it even makes sense if you're the only developer. It allows you to roll all your code back to what it was n days ago, or roll back only selected files. You can branch your code and have different versions; it allows others to review your changes and roll them back (depending on permissions).If two people work on the same file at the same time it will report the conflict and show the changes to the file in both versions side-by-side.
You can instantly roll back your code from the alpha version you worked on in the last two weeks to the version you have in production to track down and fix a bug someone found in it. If you use it properly, the code on the development server / CVS server be stable enough to do testing on it all the time (almost like a staging server).
One thing we do a lot is to "tag" the code -- this lets you put a label on the entire code base -- this is really handy when you are burning a CD of the code base or distributing code to a client who's server is inaccessible. With the label in place you can roll out code onto your workstation to exactly the distributed code -- making it much easier to decipher locally what might be going on remotely.
Oh, and there are builds of the server for different OSes, and there are a few different clients to use with them (the Daemon team uses TortoiseCVS -- http://www.tortoisecvs.org/
And it's really stable and free and open source. Unfortunately it doesn't make coffee yet but can turn the kettle on for you ;)
We also use WinCVS (http://www.wincvs.org/) -- it has some features Tortoise doesn't. I put up a mini-writeup of Tortoise on our blog a while back:
TortoiseCVS (Enjoyable Version Control) http://blog.daemon.com.au/archives/000077.html
If you have used CVS (or something similar) before these things may not sound all that new and cool to you, but it is to me since I've newer thought about using it. What do you guys use?
It is worth noting that CVS behaves quite differently to Visual Source Safe -- in CVS you typically don't lock files, you resolve conflicts. I don't really have time to elaborate on that but if you use VSS make sure you read some of the guides out there that highlight the differences in approach.
Also those of you who work in a group, do you develop and test on your local machine and then upload to a shared server? Or do you you just work on the shared server? We currently just share out the code directories on our shared dev server and just go for it. The only reason we get away with it is because it's only two of us coding. So before we implement CVS (I still have to sell the idea to Mark, who happens to be my boss) I'd like to hear some opinions.
Daemon developers typically set up their workstation to resemble the production environment -- then we all check code into CVS -- when we feel that the code in the repository is relatively stable, we label it then check it out to a staging server for testing -- that way developers shouldn't be working on the server where testing is happening.
-- geoff http://www.daemon.com.au/
--- You are currently subscribed to cfaussie as: [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED]
MX Downunder AsiaPac DevCon - http://mxdu.com/
