Tag: subversion

Svnserve Based Server

This week I decided to update my Subversion components and it did not go well. The first surprise was after updating my version of TortoiseSVN  to the 1.7 version, my Subversion icons disappeared. The fix was simple but it reminded me that it had been a long time since I updated the Svnserve server I was using from CollabNet. This would also be a nice time to add HTTP access to the repository. So I downloaded the CollabNet Subversion Edge Server and tried to get it to work with my existing repository. I ran into several problems(e.g. viewvc exception).  While researching the solutions I decided an easier solution to my problems was to install the VisualSVN Server. So I uninstalled the Edge Server, installed VisualSVN Server, and imported my repository. This worked for HTTP access but I still wanted Svnserve access since I had existing folders checked out via this method. The VisualSVN bin directory has the current version of svnserve so I needed the instructions for installing it as a windows service.  The instructions I found, Svnserve Based Server, worked for me but not until I stopped fixing things I should not be fixing in the “unusual command line” format.

Note the rather unusual command line format used by sc. In the key= value pairs there must be no space between the key and the = but there must be a space before the value.

So now I have a relatively simple Subversion server solution that works for both svnserve and http access and it should be easy to maintain.

Interfacing Subversion and Mercurial to Spiceworks

I keep our web site source files, stored procedures, and assorted programs in a source control management(SCM) program called Subversion. Since I am a small shop I track my trouble tickets using Spiceworks. My normal work flow is to enter the trouble ticket into Spiceworks and then start working on the problem. When I am finished with the problem I commit the files to the SCM and close the trouble ticket. To make life a little easier with future problems, I include a reference to the Spiceworks trouble ticket in the Subversion commit message. This could be a text version of trouble ticket number but I prefer a little nicer web interface so I implemented the bugtraq interface. This gives me a click-able link in the log that will bring up the original trouble ticket in a web browser window. This can be handy when you are troubleshooting a file that has some modification history. Implementing the bugtraq interface is pretty simple. You add two properties on your subversion repository, bugtraq:message and bugtraq:url. I set my parameters on the trunk folder properties. I set the message parameter to "Issue : %BUGID%" and the url parameter to "http://svrdev1:9675/tickets/list/all_tickets#ticket_id_%BUGID%". If you are planning to copy my parameters you should omit the double quotes and change the "svrdev1:9675" to your Spiceworks host name and port number.

If your SCM is Mercurial you can implement the bugtraq interface using these instructions, http://www.offroadcode.com/2010/10/5/better-issue-tracking-with-tortoisehg-and-kiln.aspx. The instructions are for a different SCM, Kiln, but these instructions work for any SCM you access via a url. In this case the issue link in the issue tracker changed to "http://svrdev1:9675/tickets/list/all_tickets#ticket_id_{1}".  There are several valid formats you could use. Just look at the regular expression used in setting it up for details. I used "(?i)(?:case|bugzid|Issue|#)\s*:?\s*(\d+)" for my Issue Regex. When you browse the log you should find the "Issue : 619" is an underlined, click-able link to your SCM trouble ticket.

SQL Server and Subversion

Two years ago I started supporting a  Classic ASP application that used SQL 2000 for the data base. One of the complaints of the owner was that the previous person supporting the application did not keep track of program changes. The development environment was undocumented. A test system existed  but it was in an unknown state with the production system.  It looks like it was created from a restored backup. There was an old copy of SourceSafe and Visual Studio 2003 but I was pretty sure it was not being used. I could not find any commit logs. They had a source control system(SCS) but they had not used it. Initially I tried to like Sourcesafe and the Visual Studio 2003 environment but in a Classic ASP environment it does not bring a lot to the table. The work flow is slow and not very intuitive compared to Notepad++ and TortoiseSVN. Since this is a one man shop, I had some experience with Subversion, and we were not going to upgrade Sourcesafe, I installed Subversion, Notepad++, and TortoiseSVN. Next I synchronized the code for the production and development systems and made my initial load into Subversion. This was an adequate solution for the ASP, XSL, and XML files.

The data base documentation was not existent, too. So I used SQL Enterprise Manager to script all of the tables, stored procedures, functions and views. I loaded these files into Subversion, too. Within a very short period of time I adopted SQL Management Studio Express(SSMSE) as my testing environment for SQL changes. Here is where I ran into my first SCS conflict. SSMSE scripted the SQL objects slightly differently than SQL Enterprise Manager. I wanted to develop and test SQL changes using SSMSE but I wanted the ability to script all of the SQL objects using SQL Enterprise Manager at any time. I also found the scripts created by SQL Enterprise Manager to create tables were more trustworthy. My kludge solution was to manually apply the changes to the script files created by SQL Enterprise Manager every time I wanted to commit the changes. Using WinMerge this was not difficult but it was an extra step. I yearned for a more elegant solution.

On Friday I think I found it. It was not easy to find but it looks like I can make a significant upgrade to my development environment.  I think I found it on the second or third Google page. The project resides on CodePlex.com and here is it’s description.

DBSourceTools is a GUI utility to help developers bring SQL Server databases under source control. A powerful database scripter, code editor, sql generator, and database versioning tool. Compare Schemas, create diff scripts, edit T-SQL with ease. Better than Management Studio.

Although it lists it’s status as beta, I installed it and scripted my data base without problems. Here are the features that attract me the most.

  1. You can script the entire database including the data. I have not checked out the data scripting yet.
  2. You can edit T-SQL in the same format as you used to script the entire data base if you use DBSourceTools as your editor. This should make it much easier for me to keep the source control system up to date.
  3. If everything works as advertised this should be a relatively easy way to deploy new development systems. I have been promising to deploy a development system with updated table data for over a year. I really like the idea of deploying new systems as a way to verify the integrity of your source control system.

If I can compare schemas and create diff scripts, that’s frosting on the cake. As a SQL development environment it looks very promising and the documentation is remarkably good for a new project, too. Although it is a pain in the butt I started renaming my SQL subversion files(e.g. .PRC to .sql) on Friday. This will take a long time since I am renaming the files via the repo-browser. The SVN client rename is not a rename. It adds the file to the repository and you lose the history.

Installing Subversion? Just follow this 7 Steps « Lijin’s Localhost

Great post Lijin! Sometime ago I struggled to figure out how to install subversion on my WinXP box. The biggest difficulty I had was to understand what the folder layout for Windows box should look like. I ended up using svn1clicksetup to get a standard layout. Due to issues between Subversion and Apache 2.2, I avoided using Apache for Subversion. SVNService worked just fine for me. Recently Subversion has been supporting Apache 2.2. With a slightly modified version of Lijin’s instructions I modified my XAMPP installation to support accessing my existing repositories via Apache. Here are my steps:

  1. Install Apache HTTP server if not already installed. I prefer installing Apache via XAMPP.
  2. Install Subversion and let it update your Apache configuration. In my case I was updating to the latest version. Here is my file layout:
    1. Install directory – c:\Program Files\Subversion
    2. Repositories – c:\svnrepos
    3. Apache conf file – c:\Program Files\xampp\apache\conf\httpd.conf
  3. Since my repositories are not accessible from the network, I did not create a Users authentication file or Acesss – rights file. I can do this later if I need it.
  4. In the directory, "c:\Program Files\Subversion", create a etc directory and place another file called subversion.conf with the following data. 
     
<location repos>
  DAV svn  
  SVNPath C:/svnrepos  
</location>
  5. Add Include "C:/Program Files/Subversion/etc/subversion.conf" to the Apache conf file.
  6. Restart Apache and test the repository access.
    1. I cranked up my favorite browser and went to http://localhost/repos. I saw my project directories.
    2. I created a new directory in the My Documents folder and checked out one of my projects using TortoiseSVN and the http://localhost/repos/project1 URL. It worked.
    3. Next I created a test file and added it to repository. It worked, too.

Installing Subversion? Just follow this 7 Steps « Lijin’s Localhost

Configuring Subversion to use Apache SSL

My plan was to create a subversion repository on a Linux box(CentOS) to support the configuration files I use with a virtual machine running Groundwork Open Source. This took much longer than I expected. This procedure was more complicated than usual since the latest version of CentOS requires you to create a self-signed certificate the old way since genkey and crypto-utils are no longer available.

The first step is to install subversion and configure Apache. I installed subversion and the Apache server module, mod_dav_svn, using the package manager. 

  1. I wanted one repository.
  2. I wanted to see the projects in it by typing http://myserver.com/repos/.

My initial stumbling block was figuring out where to put the repository. After fumbling around looking for a recommendation I settled on /usr/local/svn as a logical choice. So I opened a terminal window as root and created the repository, repos, with the following command:

svnadmin create /usr/local/svn/repos
chown -R apache.apache /usr/local/svn/repos

Next I imported a template directory structure with subdirectories for branches, tags, and trunk that I use for all projects.

svn import project1 file:///usr/local/svn/repos/project1 -m "Initial import"

To configure Apache to support subversion you need to edit the /etc/httpd/conf.d/subversion.conf file. The biggest problem I had with the example in the subversion manual was figuring out that I needed to use SVNPath statement rather than the SVNParentPath statement. These are the changed I made in this file.

  1. Change the location to /repos.
  2. Added the statement SVNPath /usr/local/svn/repos
  3. Followed the directions in the subversion manual to set up basic http authentication.

After restarting the httpd service you should be able to browse the repository using your web browser. The final step was to set up the web server to support SSL using a self-signed certificate. I found several tutorials out on the web. They all follow the same general procedure.

  1. Generate your private key
  2. Generate your Certificate Signing Request
  3. Generate a new key from your private key without a PassPhrase. You need this to start apache web server without prompting.
  4. Move the certificate and the insecure key over to the /etc/httpd/conf directory and change the permissions on the files so that root is the only one who can read them(i.e. chmod 400).
  5. Edit the /etc/httpd/conf.d/ssl.conf file and tell it to use the new certificate and key file.

The tutorial I used was at http://www.xenocafe.com/tutorials/linux/centos/openssl/self_signed_certificates/.  The only change I made to this procedure was to add the “-new” parameter when I was creating a CSR. After restarting the httpd you should be able to browse your repository using https://myserver.com/repos/.

SVN access available! – phpWebSite

Version control access has been restored to the phpWebSite project.

SVN access available! – phpWebSite

I had a bright idea last week.  One of the annoying aspects of phpWebSite maintenance is downloading individual modules, expanding them, and copying them over the existing modules. Why not use Subversion to update the core and mod  directories of phpWebSite? The procedure would be the same as that advocated by WordPress here. Since I recently added the Subversion client capability to my remote host, the update process would be much smoother, less error prone, and consume less bandwidth.

As a test I checked out a copy of the development version of phpWebSite to my PC. I run a local test site under Windows using XAMPP. Yea, I know I am weird thinking I can run phpWebSite under windows. I then copied over the files I needed from my existing configuration and renamed the directories. Then I went into Boost and updated the modules. After fixing the windows specific errors with updating FileCabinet and menu(i.e. creating directories did not work) modules, all of the modules are now updated and I am ready to update the site using subversion next time.

Now to make this whole scenario work for a production site we need a little help from the folks maintaining the Subversion repository. I would like to use Subversion to get the stable version rather than the development version. If they would create a tag for the stable release like the folks at WordPress, then I could use the Subversion “switch” command to update to the latest stable version. I use the switch command with WordPress to update my test blog and this is a slick way to update the files.

Variations on Updating WordPress

The folks have updated WordPress again and I have been evaluating different methods of upgrading. The standard method works but I have been wanting to streamline the process for remote hosts.

For my locally hosted blog I used the Updating WordPress with Subversion method. This is pretty slick! I had previously checked out a copy of WordPress using Subversion and integrated the wp-content and a couple other files into the working copy. All I had to do this morning was to crank up TortoiseSVN on the checked out directory, change its tag to 2.3, and let Subversion do the rest. When I logged in as Admin, it updated the database. I did get some database errors about duplicate entries into wp_terms and wp_term_taxonomy but I do not think these errors are critical since this is the blog I use to test changes with. Its pretty funky!

Yesterday I got carried away again and did a little research on using Subversion on remote hosts. I found that some host providers provide it but most do not it. My host provider, bluehost.com, does not provide Subversion support directly but I found a post on a forum that described a method I could use to install it.  I kind of followed their instructions. It is working as a client and here are my instructions.

  1. Log in using SSH. I used PuTTy.
  2. Create a bin directory.
  3. Edit the .bashrc file to add the path statement to the bin directory.
  4. Create a source directory and then change to this directory.
  5. Use wget to download the tar version of both the Subversion package and the dependencies package.
  6. Untar both packages.
  7. Run configure, make, and then make install. You should have several executables in the bin directory. 
  8. Make sure that subversion works by typing in “svn –version”.

Here is the command line version: 

mkdir ~/bin
# Use your favorite editor to edit the .bashrc file and add the path statement to the bin directory
mkdir ~/src
# get the subversion and dependencies tarballs
cd ~/src
wget http://subversion.tigris.org/downloads/subversion-1.4.5.tar.gz
wget http://subversion.tigris.org/downloads/subversion-deps-1.4.5.tar.gz
tar -xzf subversion-1.4.5.tar.gz 
tar -xzf subversion-deps-1.4.5.tar.gz 

# Build it
cd subversion-1.4.3
./configure --prefix=$HOME --without-berkeley-db --with-zlib --with-ssl
make
make install

# check it works!  
svn --version

I am now able to check out a copy of WordPress and update it on my bluehost.com website. I am not sure this is much better than the WPAU plugin I used recently. I will probably continue to play with both methods. I am still working at setting up a repository on bluehost. I do not mind using the Subversion client to update the WordPress files but I would like my bluehost account to be a server for the wp-content files since I would like version control on my theme files. It would be nice if the folks at bluehost decided to directly support Subversion, too.