> > > For our website build process what I would like to be able
> > > to do is create a deployment package that includes just the
> > > files that have changed since the last build to staging/live.
> > Why not just run 'svn update' on the live web server? Why
> reinvent all this functionality?
> My guess is that it's in the DMZ, possibly without ready
> access (or even _any_ access) to the svn server.
This doesn't always work (well update does but not the process).
Wordpress for example has a plugins directory into which ALL the plugins
reside. I'm currently figuring out a way to have both wordpress AND each
of several plugins version controlled.
This was possible with CVS as you could have a directory with files from
different sources, each linked back to their own repository.
Currently I've got wordpress and each of the plugins with their own
folder in the repository and thinking that I'll use a script in the main
wordpress folder that calls a script in each plugin's folder. The script
in the plug-ins directory (the script is different for each plug-in)
would copy the files from the plugin into the correct place in the
Wordpress tree. The reason for differing scripts for each plugin is that
some plugins have .css files, replacements for various PHP files (so
it's not quite as tidy as outlined above :-(
This is only a half-baked idea at the moment, but I want a way of trying
plugins and if necessary being able to back out. Ideally this would be a
branch on the wordpress tree (in fact this would work) but I don't want
files that originate from various plug-ins to become part of my main
wordpress repository which they would do if I just copy them in and
commit. Thinking about it this mightn't be such a bad thing but it
doesn't seem very clean.
All in all, just doing an "update" sometimes (I think) isn't quite
If anyone has any suggestions, I'd really appreciate them
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Thu Aug 4 11:09:50 2005