It's worth mentioning what our expectations of version control should be. [Version Control is also sometimes know as Revision Control, Source Control and as part of Software Configuration Management.] For a team of developers working on a project where some of the tasks overlap, I hope for a historical record of what's been done when - and of who did it. And, in addition, I also hope to minimise the occasions when today's work from one developer breaks - or even overwrites - what another developer did yesterday.
On the Dreamweaver website, it says here, and in quite a few other places, that Dreamweaver CS5 is not a full SVN client. It also says that the SVN repository and the Dreamweaver upload site are completely separate. However, it doesn't really go into the full implications of their choice to implement version control in this way.
Implementation
The core of the problem is that you can't claim to be using a version control system if you are not prepared to acknowledge that the copy of your project held under version control is truly the master copy. To put it another way, if you're using a version control system you must be prepared to give it control.
Dreamweaver's synchronisation commands use the local timestamp for the last put or get to decide whether a file has changed and therefore needs to be uploaded. Thus, if you download the up-to-date copy of a file from Subversion, then check with Dreamweaver synchronisation, it will tell you that the file has been changed and needs to overwrite the live copy even when the live copy is an identical file that was correctly uploaded.
From a practical point of view, say your day's work is started - as it should be - by downloading the latest copies of your project from Subversion. By the end of the day, Dreamweaver wants to upload all the files you changed during the day plus all the files other members of the team changed yesterday.
Say another team member has a file which should be ignored during uploads - for instance if it's a template - and the other team member has correctly marked the file to be ignored both in Dreamweaver and in Subversion. [Dreamweaver uses the term "cloaked".] When you reach the end of your day's work Dreamweaver will want to upload the file - it does not honour the ignore maker inside Subversion. ["Dreamweaver CS5 isn't honouring svn:ignore properties that are set in the repository."] And your local Dreamweaver does not know about the cloaking maker in the other team member's work area.
Another issue is the need for a second SVN client, for instance to handle some directory tasks. Most people seem to use Tortoise SVN as we have suggested in our setup guide. The trouble is that Tortoise SVN may get upgraded to use the latest version of the SVN interface ahead of Dreamweaver. (This did happen recently.) Tortoise can then write records about your files that Dreamweaver will not understand.
In this document, Andrew Voltmer, Dreamweaver's Subversion advocate describes writing scripts to run on a "build server" which would get around most of these issues - but you have first to buy, licence and configure your build server. A grumpy old project manager like myself might well say that once this effort has been invested you've nearly managed to set up a build environment as effective as a C developer had available twenty years ago.
Conclusion
In conclusion, if you have experience of something like Sourcesafe, you're in for a bit of a shock. This environment is hard to set up and it really isn't fool-proof. Developers need to be more aware of what other team members are doing than they used to be. Perhaps that's a good thing, but perhaps also it's a bit of a surprise.
On the plus side, set up as we've described, Subversion will give you a good historical record of the changes that have been made and and some chance of rolling them back. Perhaps it's worth it for that. But if your team isn't large enough to justify an individual with a title like editor or build manager, perhaps the Subversion integration isn't worth the effort.
