Most source control systems work on the assumption that each developer will check out and work on his or her own copy of the source code. This works fine for traditional development stuff (checkout, edit, compile, debug, commit, [merge]), but it tends to be a bit more difficult for web developers. To do it right, each developer needs his or her own web server or web root (at least) but this only addresses part of the problem. What to do about things like databases, web server configurations, dns setups, etc.? Yes, you can duplicate all of these for every developer and manage them with source control tools, but the overhead is substantial, especially if you work in an agency setting with many different client projects, each with a different setup (some you host, some they host, on different web servers, using different dbs, etc.) This is especially problematic in bug fixing scenarios - when the customer is screaming down the phone you don't want to spend half a day setting up an exact copy of their production environment before you can start looking for the problem, so you tend to make the fixes on the live environment and then apply them to the release version you tagged in source control. If you do this, i recommend diffing what you think you released with what's running in production. It's an education.
I've gone from using CVS in a small company to using Rational ClearCase in a big company, and have always used both the same way: multiple developers working in the same sandbox (or view in clearcase) at the same time. Yes, this means my colleagues and I can both edit the same file at the same time, with changes being overwritten just as before. Some people react as if this was some sort of cross between stupidity and criminal negligence, but source code control is about much much more than making sure that bob's changes don't squash alice's. We can see what changed, when, by who (only in clearcase - in CVS it's always the person who checked out the sandbox who checks it in, and gets the credit for all the changes), what version was released, etc. etc. - all that good stuff. And delivering code to the customer is a real pleasure - only the files that have changed, with an easy way to track what was changed and why. I'm going to preach to the choir here for a moment, but some form of source control is a real necessity for a professional developer - even if he or she works alone. Don't get hung up on which software you're using, as long as you are using something (and not the "make a zip and name it client_project.20050412.zip" approach. Or even, god forbid, use your backups as a poor man's source control.). It changes the way you work - it eliminates the fear that you're going to break something. No matter how badly you mess up the code, you will always be able to roll back - hours, days, weeks - to a time when it all worked. I used to comment out big sections of code (just in case it was something clever in stead of the bug i thought it was) - no more: select, delete, don't even flinch. And remember when you had to do all those bug fixes twice (once on the copy of the client's version and once in the new code)? Just check out two sandboxes (branch for bug fixing and head for new work) on two different servers, then merge the changes from the branch back into the head at some point. The first time i did this was after making a huge number of changes over a long long period, and i was drinking at the bar before 6 pm. /t >-----Original Message----- >From: Damien McKenna [mailto:[EMAIL PROTECTED] >Sent: Tuesday, April 12, 2005 6:44 PM >To: CF-Talk >Subject: RE: What's your setup for multiple developers > >> Paul Vernon wrote: >> > the procedures we have. Also, the one golden rule is no >> > double check outs by two developers on a single file.... >> > That is just way too much hassle.... >> >> Is this a limitation of MS SourceSafe, or of version control >> in general? > >SourceSafe is a crock. Learn it, accept it and move on. > >> I thought in cvs/svn, 2+ developers can check out the same >> file, modify and commit it without problems, so long as they work >> on different parts of the file. If they make changes that overwrite >> each other's, a conflict is thrown, which I understand, can be >> a pain. > >These conflicts are almost always a case of opening the file and >manually merging the changes between the multiple edits. These rare >occurances should never cause enough concern that a decent revision >management system is not used, that would be just foolish. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Logware (www.logware.us): a new and convenient web-based time tracking application. Start tracking and documenting hours spent on a project or with a client with Logware today. Try it for free with a 15 day trial account. http://www.houseoffusion.com/banners/view.cfm?bannerid=67 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:202437 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4 Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
