On Jan 8, 2007, at 15:25, Eric Jensen wrote:
> Was wondering if I could get some advice on setting up a good
> subversion environment for our web software. Our deployment and
> version control right now is a big headache, so I've been reading
> The Pragmatic Programmers: Pragmatic Version Control Using
> Subversion book. Problem I'm having with this book and other
> guides I've read is they all seem to be geared towards stand-alone
> compiled applications. Having a hard time translating that to a
> web environment where Apache, Database, etc come into play and have
> very specialized setups that is difficult to reproduce on a
I've noticed that too, that not only the reference materials but also
the Subversion developers are centered on compiled apps, and that
using it for web apps brings unique challenges. But they can be
This message partly describes how I worked on web projects:
> For one piece of software we have been running subversion smoothly
> for over a year now. It's a simple application that doesn't have
> any client specific customizations, so we can just update release
> candidates. But with our main application we provide heavy
> customization. We have Dev, Test, and Live servers, which is
> working out just fine. Problems is when we have 2 or 3 projects
> going on at the same time. All of them are polished and on Test,
> but only two of them need to launch up to live. So right now we
> keep track of every single file we change, then svn up each one
> individually on the live server, to make sure nothing from the 3rd
> project is accidentally pushed.
Ow, my head! That does not sound optimal.
At the very least, you should be storing this collection of files and
their revisions as a tag in the repository, so that if something bad
happens and your carefully-constructed working copy on the live
server gets destroyed, you can easily recreate it by checking out the
But if you really have diverging development happening, such that one
customer's changes should not be seen in another customer's copy of
the code, then you should be using branches and merging the changes.
> I think this is a horribly inefficient approach that isn't
> utilizing the huge advantage of version control. But without
> creating a massive mess of branches or any other complications with
> will provide more room for error, I'm not sure how to resolve it.
> Anybody know of a good SVN for the Web guide? Or even just some
> recommendations from personal experiences?
I haven't entirely understood your project setup. You have one web
app? which is used by multiple customers in multiple installations?
and each customer's copy is a bit different? In our projects which
were like that, I had the project look at a config file which was
different for each customer. (There were multiple config files
checked in, with different names, one for each customer, but there
was one central non-versioned place where you told the app which
config file to use.) The config file told the project what database
connection parameters to use, what skin to use, what features to
enable and disable, and so on. The entire project with all skins and
all features was uploaded to each customer's server, but the config
file told it what to use and what not to use.
To reply to the mailing list, please use your mailer's Reply To All
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Mon Jan 8 23:22:07 2007