You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Marc <su...@advantex.net> on 2006/09/20 15:26:20 UTC

Subversion and the Dynamic Website

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

RE: Subversion and the Dynamic Website

Posted by Marc <su...@advantex.net>.
Okay, so I've been experimenting... Here's what I have on our remote server:

C:\web\sites\svntest.website.com
C:\web\sites\svntest.website.com.dev
C:\web\sites\svntest.website.com.repo


The contents of "svntest.website.com" and "svntest.website.com.dev" are
exactly the same:

	www\index.cfm

Those two directories represent the virtual web hosts for the
development/staging/qa site, and the live website.  The www directory in
each of those two directories is shared via IIS.

The repository is in svntest.website.com.repo.

I imported svntest.website.com.dev into the repository.  So now the
repository has the following structure:

file:///c:/web/sites/svntest.website.com.repo
-- trunk
---- www
------ index.cfm

I can connect to the repository on the server, remotely
(svn://myserver.site.com/), and I can Checkout the /trunk directory, make
modifications to index.cfm, save, update, and commit.

I'm having trouble understanding the workflow from here, both with creating
the dev site that will be used, and creating the live website checkout or
merge.

First... When I edited and saved index.cfm, and then did the recommended
"svn update" and then "svn commit" all went well.  From the server site
Tortoise, I can see that the revision number went up. The log file for
index.cfm shows my username as the most recent revision.  The repository IS
working.

Now, since the entire contents of the .dev directory was initially imported,
should I delete and recreate svntest.website.com.dev, and then do an svn
checkout, or should I delete it, recreate it, and do an svn export?  The end
result I am looking for is that each time the repository gets a commit from
a client, it should immediately write out the changes to the dev site, so
that the changes can be tested right away.  This means I'll have to create a
hook after commit, that does either the update or the export.

Then, when the dev site is considered 'up to date', I will deal with
updating the live site...

I saw no way to share the repository file/folder structure 'as' the dev site
directly... I am making the assumption that the dev and live sites both need
to act as one-way (repo --> site) updating working copies... The dev site
updating immediately on each repo commit, the live site being updated only
on demand, after the dev site has been reviewed for bugs.

Is this the proper work flow?  (yes, this still does not deal with the
dynamic content being created through the USE of the code... But I'll deal
with that later...)

Am I in the ballpark here, or is this more complex than it needs to be?

Thanks,

Marc


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Subversion and the Dynamic Website

Posted by Johnathan Gifford <jg...@wernervas.com>.
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
<56...@cylon1.sjc.collab.net>, "Marc"
<su...@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