If your ColdFusion developers are using Eclipse with the CFEclipse
plug-in, consider using the Subclipse plug-in for Eclipse to facilitate
Subversion interactions. This way, your developers don't have to go in
and out of th IDE to commit changes. It also allows your designers on
Mac's (if you have any) to work the same way.
To test your site on the development (aka QA) server and to deploy to
production, consider make your websites (including production) a
Subversion working copy. This allows for easy deployments and quick
rollbacks through the command line with this simple command, svn update
-r XXXXX (We XXXX is your revision number that your rolling out or back
to). All from Subversion with the command line client. No FTP, or
other protocol getting in the way or going through five windows and
forgetting a file. We've been doing this since Janaury with our
ColdFusion site. Rollouts are a breeze. Rollbacks are cinch. And we
know everything made it to the site as we intended.
A couple of things to do if you use the working copy approach to
deployments. First, checkout the site to your server with account that
does not have write privileges to the repository. As you should never
do development or changes on production and put them back. Second, make
sure you website cannot server up the .svn folder or anything in it.
Now, to the question about your CMS stuff. Create a second Subversion
repository (heck, create a new Subversion server, on the production
server). Access all the content via http from the Subversion repository
containing all the CMS files. Your developers can write code to get the
contents of the directory and map the link URL's straight to the
repository. To make this work, everyone and anyone must have read
access to the repository. To write, they will have to authenticate.
You can do this by setting up the CMS repository utilizing WebDAV and
auto versioning in Subversion. However, Windows Explorer does some
goofy things with WebDAV on Apache and authenticating with anonymous
access. Test it out. Have your users try it and see if it just bugs
them. If it does, find another way. It if doesn't, push forth. If you
control the upload of content through ColdFusion, your developers could
use the <cfexecute> command and commit the content to the repository.
>>> On Wed, Sep 20, 2006 at 10:26 AM, in message
> Hello Everyone,
> I am new to Subversion (haven't even set up my first project yet!),
> looking forward to using it in our small company.
> Our immediate need is to version- control a dynamic (ColdFusion-
> After reading (and reading, and reading!), I have decided on this
> layout/business process, in theory:
> Platforms: Windows 2003/IIS/ColdFusion 6.1/SQL Server 2000. Will
> instruct developers to use TortoiseSVN.
> I plan on implementing the best- practice project/directory layout.
> The TRUNK of the project would be served up by the web server as
> A svn working copy of TRUNK is served up as www.site.com, and is
> updated" when dev.site.com is working properly after updates from
> Developers can check out files or directories or entire trunk. This
> the files on their local file system.
> We probably won't use branches right away, but might consider tagging
> "versions" of the website after any major changes.
> If the developer has local install of the site, with web server/cf
> connected to the DEV snapshot database, they can modify and test
> locally, and commit back to the trunk when done.
> If the developer does NOT have a local copy, they can modify code and
> back to trunk, and use the dev.site.com to check their work.
> A working dev site is therefore absolutely required prior to svn
> TRUNK to the live site. All testing is done on dev.site.com by as
> people as possible, before deployment.
> Database snapshots from LIVE to DEV can be done as- needed via DTS
> run using a CF page. The database schema rarely if ever changes, and
> schema changes all go through one person.
> Live site checkout, once dev.site.com is tested, will be made
possible via a
> call to a CF page that runs an svn update, which updates the live
> code with the latest TRUNK.
> This all seems like it will work great. Then there's the Big But:
> What about dynamic content created by CMS users of the live site?
> Specifically, the site we want to VC has code that allows content
> to upload images, pdfs, and other "file- based data". I'm not sure
> file- based data should relate to the VC system. The ultimate would
> have the file- based data sync'd back to the dev/VC system.
> I've read a lot on how to do this, and have gotten this far... But
> ability for the code itself to allow file uploads into directories
> the code itself is the sticking point. Moving the storage location
> file- based data is not an option unfortunately, as the developer has
> of dependencies between the code and the data file director(ies) that
> don't want to toy with and have to debug on a large scale.
> So, gurus, how should we proceed... Or is Subversion not the right
> this job?
> Thanks everyone!
> To unsubscribe, e- mail: users- email@example.com
> For additional commands, e- mail: users- firstname.lastname@example.org
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Wed Sep 20 18:20:08 2006