Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Our development team has a live server hosted in a data centre, as well as a dev and staging server onsite

All machines are running Debian 5, PHP, MySQL

We have Subversion running on the development box

We use Dreamweaver CS5

As I understand it, Dreamweaver can connect to the subversion reposity and manage checking/checking out etc, we can also specify connections to the staging and production server

I am trying to get my head around the work flow, essentially our guys will work on local copies of files, will they lock the file/s they are working on, then commit the changes when complete?

Then, when complete and tested, Dreamweaver can upload to staging for further testing, then when done again Dreamweaver can upload to production.

Is this a resonable way to work?

Am I missing something here?

Could someone give me a run down?

share

locked by HopelessN00b Jan 21 '15 at 10:33

This question exists because it has historical significance, but it is not considered a good, on-topic question for this site, so please do not use it as evidence that you can ask similar questions here. This question and its answers are frozen and cannot be changed. More info: help center.

closed as primarily opinion-based by HopelessN00b Jan 21 '15 at 10:33

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.If this question can be reworded to fit the rules in the help center, please edit the question.

up vote 1 down vote accepted

Here's how I do it:

We use Subversion on our dev box. Everything gets checked in: documentation, config, source code, graphics, you name it. Dreamweaver would check in/out on the development box only in this scenario. Also checked in is a build script, which copies everything out to the root, sets ownerships and permissions, and reloads the daemons. This is great, because the developers have sudo privs to run it whenever they want.

To promote, we use a simple little script that does an 'svn export' to a tarball. The tarball gets manually moved to production, unpacked, and an admin runs the build script.

Totally repeatable and reliable. It makes me happy everytime we use it.

share
    
When you say copies everything to root, do you mean the document root? And therefore makes makes "live" on the dev box? – Tim Sep 4 '10 at 13:25
    
No, to the OS root. That happens to include the DocRoot though. Since the whole project is checked in, there are all sorts of other things that need to get laid down: source code, documentation, utility scripts, developer notes, cron jobs, you name it. Our goal is to have "vendor_build + subversion_repo = working machine". – pboin Sep 9 '10 at 17:10
    
@pboin, hopefully you're still active here, as this answer is pretty old now. I'm trying to do the same thing - use Dreamweaver to push updated content from SVN to production. Is this still your workflow? Or is there a way in CS5 and/or CS6 to mange an SVN update directly without having to TS into the server and do it with TortoiseSVN? – kristina childs Apr 23 '13 at 18:47

I am trying to get my head around the work flow, essentially our guys will work on local copies of files, will they lock the file/s they are working on, then commit the changes when complete?

Appears that Dreamweaver doesn't force you to lock the files (we don't use it with Subversion). This works because Subversion has the ability to merge commits. However if in some cases when a merge can not be cleanly done Subversion will give you a conflict message requiring attention (when updating) or block your commit. These alerts should be shown and able to be handled by the Dreamweaver GUI.

Then, when complete and tested, Dreamweaver can upload to staging for further testing, then when done again Dreamweaver can upload to production. Is this a resonable way to work?

It may be. In our similar app deployment setup (dev, staging, production) there is no syncing from dev to production. The sync to production is only from whatever is on staging as that is what has been tested and approved by the client. We do it this way to avoid any potential of an erroneous change finding it's way on production.

share

Not the answer you're looking for? Browse other questions tagged or ask your own question.