Showing posts with label svn. Show all posts
Showing posts with label svn. Show all posts

Friday, May 7, 2010

Grep Subversion log messages with svn-grep

Back in the days when I used branches sparingly, I used the Subversion log messages to track features I was working on. When working simultaneously on two distinct features (e.g. SITE_REDESIGN and SWITCH_LANGUAGE), I tried to commit the changes separately for each feature, so my log messages looked similar to this:
r1000
SITE_REDESIGN
 - fixed CSS code for MSIE
 - redesign product pages

r1001
SWITCH_LANGUAGE
 - added language switcher to header
That way when looking at the log history, I immediately knew which commit was related to which feature. Today I needed to port some my changes to a different repository - so I had to check all the revisions related to e.g. SITE_REDESIGN feature and review them. It's an easy task in TortoiseSVN, however I'm on Linux now (and extraordinary RabbitVCS does not yet have the feature of searching in log messages). So I wrote a small tool that would do the task for me - and here I present you with

svn-grep

With this tool, you could easily search all your commit history for a given string and save accompanying log messages and diff files in a specified directory for review. You could use it for tracking poor-man's branches as I am, find a bugfix for a given bug etc.

Example

$ cd my-project
$ svn-grep SWITCH_LANGUAGE
This will fetch all logs & diff files for all revisions having SWITCH_LANGUAGE in log message and put it into my-project/report-SWITCH_LANGUAGE. So in one central place you have all the related files and you could, as I am right now, manually review and port the feature to a similar project.

Download and info

svn-grep is hosted at GitHub alongside with my other tools for Subversion (currently the script exporting a working copy to a zip). It's MIT-licensed, so you can freely download & use it. You're also welcome to fork the project and introduce some new features for it, right now it's just a newborn baby :)

See the project page for download and more info.

But it still looks like I'm moving slowly into git...

Thursday, September 24, 2009

Using shared SVN working copy on samba

Part of deployment procedure for PHP applications in company I work for is to update the code on a staging server through a samba share. The code is then replicated to production machines.

We use Subversion as our VCS of choice so we simply kept working copies on staging server and used TortoiseSVN to do an svn update. Later on we would e.g. migrate the database, update configuration files etc. This proved to be very simple and effective technique.

However,when our administration changed authentication procedures and gave every developer separate account (we used a single user name to log in to our samba share before, now we authorize through NT domain) - it suddenly stopped being so effective.

As soon as one developer updated the staging working copy, he started "owning it". Anyone else trying to update it later on got access denied errors. The reason? Subversion client created files in .svn that are read-only and these could not be deleted and recreated by anyone else (and Subversion client does this during svn update).

Luckily, there is an easy solution, found here and also mentioned in SVN FAQ. In our case, inserting:
[global]
delete readonly = yes
in smb.conf solved our problem. Any developer that is authenticated to use our staging share may now update the working copy.

Disclaimer: Although using working copy on samba share is not recommended by Subversion team, we use this technique for years now with different server and client versions and this was our first problem. However - we don't do development on this working copy, we only update it, so it's not a real full-blown multiuser working copy.