Content tagged with: subversion

Merging a subversion branch back into trunk

Submitted by Eric on Sat, 01/30/2010 - 09:44

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

# First you'll need a local working copy of your trunk
$ cd /path/to/checkout/trunk
$ svn co https://HOSTNAME/repo/trunk .

# The above command will return the latest revision of the trunk
# which you'll need to remember for a later command. Example:
Checked out revision 76.

# If you already have a working copy of your trunk,
# running an "svn update" will set your repo to the latest revision
# and return the latest revision:
$ cd /path/to/checkout/trunk
$ svn update
At revision 76.

# Now, you'll need to find the revision when the branch was created:
$ svn log --stop-on-copy https://HOSTNAME/repo/branches/20091205 | tail -5
------------------------------------------------------------------------
r63 | eric | 2009-10-07 15:10:28 -0400 (Wed, 07 Oct 2009) | 1 line

Created branch.
------------------------------------------------------------------------

# Now that you know the latest trunk revision and the branch created revision,
# you can execute the merge on your local working copy of trunk
# NOTE: it would be a good idea to ensure you are not executing the merge
# in an active environment!
$ cd /path/to/checkout/trunk
$ svn merge -r 63:76 https://HOSTNAME/repo/branches/20091205 .

# NOTE: the revision range syntax is: "-r BRANCH:TRUNK"

# Now if you execute an "svn stat" command you'll see that all the changes from your branch have been applied to your working copy of trunk. Hopefully, there are no conflicts! Now you can review the changes, test your code, and commit.

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

# find the branch created revision:
$ svn log --stop-on-copy https://HOSTNAME/repo/branches/20091205 | tail -5
------------------------------------------------------------------------
r63 | eric | 2009-10-07 15:10:28 -0400 (Wed, 07 Oct 2009) | 1 line

Created branch.
------------------------------------------------------------------------

# find the latest revision of trunk:
$ svn info https://HOSTNAME/repo/trunk | grep -i ^Last\ Changed\ Rev
Last Changed Rev: 76

# from checked out local copy of branch:
$ svn merge -r 63:76 https://HOSTNAME/repo/trunk .

3 comments

Creating a module update function to disable your development modules when deploying to production

Submitted by Eric on Mon, 10/12/2009 - 18:06

There are some great development modules for Drupal (Devel, Coder, Reroute_Email, Demo, etc), but you probably don't want to have them enabled in a production environment. Deployments to production can be simplified by adding a hook_update_N function in your module's .install file. In this function you can take care of administrative functions such as importing views and CCK node type definitions (essentially, anything exportable). In this quick code snippet, I'll show how you can create a module update function to disable your development modules on update.

<?php
// NOTE: see the documentation on hook_update_N for version naming conventions
function MYMODULE_update_6100() {
  
  // check for production environment hostname
  if ($_SERVER['HTTP_HOST'] == 'your-production-hostname') {
    
    // rebuild the module cache
    module_rebuild_cache();
    
    // define a list of development modules to disable
    $modules_disable = array(
      'reroute_email',
      'coder',
      'demo',
      'performance',
      'devel_node_access',
      'devel_generate',
      'devel_themer',
      'devel',
    );
    
    // disable modules
    module_disable($modules_disable);

  }

}
?>

Now that your module update function is created, you can deploy your file updates to production (preferably using subversion) and run the update.php script, apply your module update, and disable your development modules.

Add new comment

Installing subversion on a Mac and handling differences in Subversion repository versions

Submitted by Eric on Tue, 09/15/2009 - 19:05

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

$ which svn
/usr/bin/svn

$ /usr/bin/svn --version | head -1
svn, version 1.6.2 (r37639)

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):

# lines added to /etc/profile:
export PATH=/opt/subversion/bin:$PATH

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

$ which svn
/opt/subversion/bin/svn

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

$ cd /path/to/my/1.6.x/repo

$ svn stat
svn: This client is too old to work with working copy '.'.  You need
to get a newer Subversion client, or to downgrade this working copy.
See http://subversion.tigris.org/faq.html#working-copy-format-change
for details.

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:

$ svn --version | head -1
svn, version 1.5.7 (r36142)

$ cd /path/to/my/1.6.x/repo

$ change-svn-wc-format.py . 1.5
Converted WC at '.' into format 9 for Subversion 1.5

Add new comment

Resolving the subversion error: svn: Can't create directory 'sites/default/files/some/path/.svn': Permission denied

Submitted by Eric on Mon, 08/03/2009 - 07:15

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:

svn: Can't create directory 'sites/default/files/some/path/.svn': Permission denied

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 (~):

$ svn stat
~      sites/default/files/some/path
~      sites/default/files/some/other/path

You'll first need to reset permissions and ownership:

# change directories, you don't want to reset every file permission
$ cd sites/default/files

# use a find command and "-exec" switch to reset ownership and permissions
# NOTE: the group, owner, and permissions will vary on every server configuration
$ find . -exec chown Eric.apache {} \; -exec chmod -R ug+rw {} \;

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

$ svn stat
~      sites/default/files/some/path
~      sites/default/files/some/other/path
$ svn revert "sites/default/files/some/path"
$ svn revert "sites/default/files/some/other/path"
$ svn stat
?      sites/default/files/some/path
?      sites/default/files/some/other/path

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

Add new comment

Upgrading a Subversion-integrated Drupal site, part 2

Submitted by Eric on Tue, 02/03/2009 - 15:36

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

$ wget http://ftp.drupal.org/files/projects/drupal-6.8.tar.gz
$ wget http://ftp.drupal.org/files/projects/drupal-6.9.tar.gz

Next, unpack both of the files:

$ tar -xzf drupal-6.8.tar.gz
$ tar -xzf drupal-6.9.tar.gz

Now, use the diff command to compare the directories:

$ diff -r -q drupal-6.8 drupal-6.9

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

Files drupal-6.8/CHANGELOG.txt and drupal-6.9/CHANGELOG.txt differ

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:

$ diff -r -q drupal-6.8 drupal-6.9 | grep -iv differ$

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.

# check how many file modifications there are:
$ diff -r -q drupal-6.8 drupal-6.9 | wc -l
83

# copy the files into your current Drupal installation:
$ cp -r drupal-6.9/* /path/to/your/drupal/installation/httpdocs/

# verfiy the same number of file modifications:
$ svn stat /path/to/your/drupal/installation/httpdocs/ | grep ^M | wc -l
83

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

$ svn commit /path/to/your/drupal/installation/httpdocs/ -m "Upgraded Drupal from 6.8 to 6.9"

3 comments