On 3 May 2010 17:02, doug <ddjol...@gmail.com> wrote: >> Why do you need this system rather than just pulling down the latest >> version from source control ? > > Because there are some files that may have been modified with customer- > specific code. We never want to overwrite these files. However, if a > file in this group doesn't exist on the system being updated (as in > the case where the update adds the file) we want to write the file.
So you *don't* have a SCR-managed version of your different client sites differences? Well... that's not the most unusual situation, but it's not exactly great practice. I'd suggest a review of your internal processes with all the developers, PMs and other stakeholders to discuss how to manage code deployment. As a suggestion, I'd recommend a branch of your code for each of your deployed client sites. Using Git/Mercurial it's not a huge nightmare to manage merging core changes while keeping client-specific code in the respective branches (although I'd recommend that was a task delegated to one "change manager" who can keep on top of it, and be responsible for all changes - and banging the heads of anyone who "breaks the build" :-) Approaching the problem this way, you can deal with any updates in source control long before deployment, ensuring the client is going to get the right stuff (and with a staging server, that everything is going to continue working). Approaching it from the angle you're musing about, you'll be constantly walking a tightrope that you accidentally apply the wrong tar file to the wrong site - and that's on the live site too. HTH -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-t...@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-talk+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
