Marc,
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.
Johnathan
>>> On Wed, Sep 20, 2006 at 10:26 AM, in message
<56vbav$115nt8@cylon1.sjc.collab.net>, "Marc"
<subscriptions@advantex.net>
wrote:
> Hello Everyone,
>
> I am new to Subversion (haven't even set up my first project yet!),
but am
> looking forward to using it in our small company.
>
> Our immediate need is to version- control a dynamic (ColdFusion-
based)
> website.
>
> 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
probably
> 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
> dev.site.com.
>
> A svn working copy of TRUNK is served up as www.site.com, and is
"svn
> updated" when dev.site.com is working properly after updates from
anyone.
>
> Developers can check out files or directories or entire trunk. This
places
> the files on their local file system.
>
> We probably won't use branches right away, but might consider tagging
of
> "versions" of the website after any major changes.
>
> If the developer has local install of the site, with web server/cf
server
> connected to the DEV snapshot database, they can modify and test
code
> locally, and commit back to the trunk when done.
>
> If the developer does NOT have a local copy, they can modify code and
commit
> back to trunk, and use the dev.site.com to check their work.
>
> A working dev site is therefore absolutely required prior to svn
update of
> TRUNK to the live site. All testing is done on dev.site.com by as
many
> people as possible, before deployment.
>
> Database snapshots from LIVE to DEV can be done as- needed via DTS
package,
> run using a CF page. The database schema rarely if ever changes, and
those
> 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
site's
> 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
managers
> to upload images, pdfs, and other "file- based data". I'm not sure
how this
> file- based data should relate to the VC system. The ultimate would
be to
> 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
the
> ability for the code itself to allow file uploads into directories
shared BY
> the code itself is the sticking point. Moving the storage location
for this
> file- based data is not an option unfortunately, as the developer has
a lot
> of dependencies between the code and the data file director(ies) that
we
> 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
tool for
> this job?
>
> Thanks everyone!
>
> marc
>
>
---------------------------------------------------------------------
> To unsubscribe, e- mail: users- unsubscribe@subversion.tigris.org
> For additional commands, e- mail: users- help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Sep 20 18:20:08 2006