Take the 2-minute tour ×
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.

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 '13 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 '13 at 18:14
    
Is there the possibility to use git? It's much more efficient at handling filesystem fiddles. –  Florian Margaine Feb 24 '13 at 17:07
    
@florian. Not at this point –  jdog Feb 25 '13 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 '13 at 21:11
show 1 more comment

4 Answers

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 '13 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 '13 at 23:23
add comment

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 '13 at 3:32
add comment

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 '13 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 '13 at 15:31
add comment

You forgot to mention some significant things:

  • Does sites (in core or|and in modules) have customer-specific changes or they use vanilla code?
  • Are clients sites also Working Copies of SVN-repos or unversioned trees?
  • Why (at least for WP, can't recall Joomla state for today) you don't use embedded updater, which can update all - core, modules, themes?

Anyway, your current process doesn't have any sense (for me). In order to update in your repository external code, also served by SCM, you can have a lot less operations

WP, no local modifications

  • Link your trunk (with externals) to latest tag of WP's core in WP-repository
  • Link all used in installation Wordpress plugins to latest tags of these plugins in WP-plugins repository (combine all external definitions in one common location for better manageability)

When new release of anything will appear, you have only:

  • Change external of this anything in order to link to new tag
  • Update tree (updates will appear in your WC automagically)
  • Commit changes and deploy new version of site to destination

WP, local modifications

For existing local changes workflow will be changed only in some details: your code will be in trunk, vendor's code - in some (RO) branches (also externaliz'ed), which you merge to trunk after update

Same tricks can be applied to Joomla, maybe just one-two more will be needed, when (if) Joomla will change SCM-backend from Subversion

share|improve this answer
    
You are right in principle. I use svn repos for the sites. Most of these sites have a lot of custom code, if I used the updater, then all my code would have to be packaged, which is unnecessary overhead. Also, I have used this method for years for Joomla 1.0 and 1.5 sites. One additional challenge is that Joomla has 3 kinds of extensions, which use at least 5 folders in my case. You are right, its not impossible to achieve –  jdog May 22 '13 at 16:34
add comment

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.