Tell me more ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.
up vote 3 down vote favorite

We manage a range of client sites built in Wordpress and Joomla and these require regular updates to the core CMS and extensions. We keep these sites in subversion and place updates in subversion. We try to use a single revision for this.

We face some difficulties in making this process efficient, over time we would like to automate it, so we can offer the process on a fixed price basis

The process is currently as follows

  1. make copy of whole folder

  2. svn status |grep '^!' |sed 's/^!\s*/svn delete "/g' |sed 's/$/"/g' |sh

  3. svn update

  4. svn status |grep '^?' |sed 's/^?\s*/svn add "/g' |sed 's/$/"/g' |sh

  5. svn ci -m "Commit message"

  6. svn remove -m"temporarily remove" http://subversion.repository.com/svn/automatem/projects/client/trunk/project/foldername

Steps 5-6 are usually repeated multiple times.

What I'm looking for help with

  • we are using subversion version 1.6 and 1.7, because there are no .svn folders in 1.7 in subdirectories, I wonder if the process is much easier on 1.7?

  • we've added step 3 because it reduces the number of repeats in steps 5-6. However this was just trial and error and I can't quite get my head around why this is

  • As I understand it, the issue in step 5-6 is that when the an extension is updated, it may delete a whole folder and then re-insert that folder with changed files. In subversion 1.6, this would remove the .svn folder, which causes a 405 Access denied error (the folder gets added, but already exists in svn). What I would need is something that inserts all .svn folders back into my working copy if the folder already exists in svn. Is there a way to accomplish this?

  • Any other improvements of course appreciated.

share|improve this question
1  
I smell a good question behind a very bad description. If you want to get some answers, please phrase clearly what you want to know, which part of the process you think might be have to improved, where you have problems (and please, improve the formatting). – Doc Brown Feb 15 at 7:23
Thanks, I didn't take enough time first time around. I hope you have a good sense of smell ;) – jdog Feb 18 at 18:14
Is there the possibility to use git? It's much more efficient at handling filesystem fiddles. – Florian Margaine Feb 24 at 17:07
@florian. Not at this point – jdog Feb 25 at 3:32
I think you can find the answer in: stackoverflow.com/questions/61888/… One of the bottom answers has code very similar to the task you are trying to accomplish. You should definitely switch to subversion 1.7 and checkout the copy in the parent directory of your website (the only one that will have a .svn subfolder), even better if it is not visible from your ftp client (beyond the ftp root), so nobody can delete it accidentally. – user85090 Mar 21 at 21:11
show 1 more comment

3 Answers

up vote 0 down vote

The problem you are facing is better solved using tools other than SubVersion. As a gross (mis)characterisation, SubVersion was developed around 10 years ago, with the main goal of being better than CVS because it managed directories as well as files. As a version control product its very capable, and one that I have used in the past on serious projects. However....

What you need is not version control, but change management. You need to manage the delta that a change creates in the software, but also where that change should be applied.

The free option, I'd use GIT, but if your company has the money, then Accurev is a better technical choice for this kind of problem.

With git, you would create a branch that just contains the base code for joomla, and then do each of your customer sites in seperate branches. When you are ready to pull in the current joomla version you would issue a git command such as 'git pull origin joomla' to pull in changes from branch 'joomla' Whilst this would work, the weakness is that you would need to know that an update was in joomla, and that you need to remember to pull in the changes.

With Accurev, you would create a stream that contains the joomla code, and you would tag each release. Then, in your projects stream heirachy, you would then cross link your joomla directory to the tagged revision level.

The advantages Accurev gives you over git is that you can explicitly change your cross link to any tagged version of joomla. Including rolling back a version. You have visibility of which version is currently being used, and you can easily find where each taged version is currently used. (e.g. look for the projects that are still using a old and vulnerable version of joomla). The downside is the cost of the product, the learning curve for the developers to adjust to the new way of thinking (that some will just not get it), and that the developers will inevitably grumble about the Accurev GUI.

share|improve this answer
Thank you. For a wide variety of reasons I can not simply change from subversion, I'm looking for improvements that still use svn – jdog Feb 25 at 3:32
up vote 0 down vote

This looks like a good job for externals. Joomla and Wordpress are both hosted on subversion, which makes externals a natural fit. Basically, instead of making your own copy of a folder and trying to manage the changes, you tell it this folder should be pulled from a certain revision from a certain external repository.

share|improve this answer
Good idea, I'm using externals already for Symfony projects. Because Joomla extensions go into at least 5 different folders, it'll be a long list, but I guess I only have to do this once. The other complication is that Joomla moved to git with 3.0 I think, but I'll double check that. – jdog Feb 25 at 21:37
Joomla moving to git shouldn't matter, you probably want to extern to your own copies of the CMS cores to insulate you against upstream changes. – Wyatt Barnett Mar 21 at 23:23
up vote 0 down vote

Upgrading to SVN 1.7 will help alot -- it makes SVN almost bearable.

If I was stuck managing something like this in SVN and I didn't want to look at using svn externals, I would take a much different tactic here -- I would not version the core CMS with the framework at all but rather have that in a separate repo that could be pulled via svn export when needed. Upgrades involve just deploying to a new folder.

share|improve this answer
can you elaborate a bit on how svn export would be used. The problem with Joomla is that every extension modifies usually 4 or more folders with Joomla. So the core system and extensions (3rd party of custom developed) are heavily intermingled – jdog Mar 26 at 7:27
Not much seat time with joomla so I can't speak to that directly, but what you can do is basically setup a build process where the base joomla install is SVN exported then you just check out your code (including extensions) on top of it. Another way to handle much of this, if there are just specifcic folders you need to separate out then symlinks are a man's best friends. – Wyatt Barnett Mar 26 at 15:31

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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