[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: RE: Re: Getting list of files that changed between revisions

From: Moretti, Giovanni <G.Moretti_at_massey.ac.nz>
Date: 2005-08-04 09:29:05 CEST

> > > 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 would copy the files from the plugin into the correct place in the Wordpress tree (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 backed 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 trunk 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 enough ...

If anyone has any suggestions, I'd really appreciate them

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Aug 4 10:09:46 2005

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.