Content tagged with: svn

Here's an tutorial explaining how to merge a subversion branch back into trunk:

If you need to merge some changes made to trunk into your branch, you could do the following:

When I got my new MacBook Pro, I installed Xcode which comes with subversion (version 1.6.x):

After installing Xcode I checked out some repositories to my local filesystem. Soon afterward, I realized I needed to be running an older subversion client to stay compatible with some 1.5.x repositories, so I decided to install CollabNet's OSX subversion binary (registration is required for older releases).

After downloading and installing the package (which defaults to /opt/subversion/bin/svn), I edited the /etc/profile file to override priority of my $PATH variable (since I now had 2 versions of subversion installed):

Now, if I ran a "which" command for svn, the appropriate svn executable is returned:

Unfortunately, the subversion projects I checked out using Xcode's subversion were inaccessible due to differences in the .svn structure:

Luckily, CollabNet has a downloadable python script which allows you to switch checked out repositories to different versions. I downloaded this file and copied it into /opt/subversion/bin.

I was now able to update/downgrade my repositories using this python script:

Version control is an essential tool when it comes to maintaining your code and properly tracking filesystem changes. In this quick tutorial, I'll show you how to update a Drupal module in a subversion integrated environment using rsync. Since simply copying the contents of a new module update on top of your current directory structure is a bad idea (since it will NOT account for file deletions), rsync is a great solution for syncing module update changes. NOTE: it is a bad idea to update a module in a production environment without proper testing; this code assumes you are working in a development environment.

The first step is to download the latest (and in most cases, stable) package for the module you'd like to update to a directory outside your drupal path. For my Drupal installations, I browse to the Available updates page (admin/reports/updates) and copy the URL from this page. Next I go to my shell, use wget to fetch the package to my home directory, and unpack the file:

Now you can run the rsync command to apply the filesystem changes to your Drupal module directory. You'll have to update the paths listed below to match your filesystem and Drupal installation.

If executed properly, you can change directory to the module you are trying to update and run an "svn stat" command to see what has been updated. NOTE: the below output is simulated to show common svn status changes.

At this point, you should see a list of all the files that have changed with this module update. You can now run the update.php script in your development environment and verify the changes are working properly. If everything is working properly, you can commit the module update changes...

Now, you can safely deploy the module changes to your production environment (svn update), run the update.php script, and ensure everything is working properly.

There is nothing more frustrating than not having permissions set correctly on a server. I recently tried to commit a bunch of files to subversion and received the following error:

This usually indicates your user does not have permission to alter the .svn folders to execute the subversion commit command. The failed command will leave your subversion status with a tilde (~):

You'll first need to reset permissions and ownership:

Now, you can revert the files to remove the tilde (~) status:

At this point, you should be able to re-add the files to subversion and commit.

Back in December 2008 I posted a blog entry on how to upgrade a subversion integrated Drupal site. This procedure was based on the process of unpacking the new Drupal installation, copying the sites folder into the new Drupal installation, and checking everything back into subversion. Although this is the recommended and cleanest way to upgrade Drupal, it may be a hassle if you have a huge repository and lots of files. So why not just overwrite the old directory with the new Drupal files? Well first of all, it would be good to take into consideration file deletions; and second, I've always been the kind of person who believes in fresh installs. I'd rather reinstall my operation system versus upgrading it. If you insist on overwriting the files, here's how you can do it...

Go to /admin/reports/updates to checkout which version your currently running and which is recommended. Download the new version of Drupal, along with the current version of your Drupal installation. If you can't find the current version, look for the "View all releases" link here: http://drupal.org/project/drupal

Next, unpack both of the files:

Now, use the diff command to compare the directories:

You'll see a lines of output that resemble the following:

Files that differ are OK, we can easily copy them into our current installation and check them in as modifications. To ignore those lines, we can run the previous command and tack on a grep statement to ignore them:

Hopefully, the previous command will return no output. If the diff command returned any output, it's probably telling you a file exists in one version and not the other. You'll have to manually resolve these subversion changes.

If the previous diff command returned no output, the new Drupal installation can be simply be copied on top of your current installation. But first, let's keep track of how many changes there were. NOTE: the next command assumes your current Drupal environment is up to date (the HEAD revision) and every file has been checked into the repository prior to the upgrade.

If the numbers match, run the update.php script. And if all went well, commit the changes: