Archive for the ‘SVN’ Category

Tip for a SVN project

Monday, May 9th, 2011

Ok, this is the scenario:

There is a huge project hosted on a SVN repo. I’m to start a new project based on that one… No, I’m not allowed to create a new branch. And I must upload this project to a new SVN repo.

So checking out the project is easy. Now that I have the project in my Mac I want to be able to check it into the new SVN repo, the only thing is that when I checked out the project it downloaded to mi machine with a whole bunch of “.svn” folders.

Now, there are 2 different ways to get a clean copy of a project from a repo.

1. Do an export instead of a checkout, this will give you a project copy without the annoying “.svn” folders.

2. Do a regular checkout and then delete all the “.svn” folders.

On my humble opinion it’s better to do an export. If you do a checkout you can delete the “.svn” folders manually but be aware if you have lots of folders because an “.svn” folder will be created within each of your project’s folder so if you have a project with 10 folders and each one with two subfolders you’ll have to go into each f them to delete the “.svn” folders manually… it’s easy but it might take a lot of time and resources you might not have.

To speed up things it’s better to do the following:

Go to your project’s folder and run the following command:

find . -name ".svn" -type d -exec rm -rf {} \;

It will search for all directories called “.svn” and delete them as well as it’s contents.
I found this to be very useful and I really use it frequently but I keep forgetting it so I’m posting it here ūüėÄ

Code maintenance

Wednesday, October 20th, 2010

Keeping track of code through time is a very delicate task.

It gets to be a really important issue when customers are making usability tests to a program. You make some changes, the customer reviews them, approves and you send them to production, a couple of days later the customer changes his mind and ask you to go back to how the program looked 3 months ago.

That scenario gets to be very common in web development and can be a serious problem if you don’t give your customer what he wants. How could you go back to a 3 months old version of a page? Did you backed up your files? Is your presentation layer different from the logic one? What has changed since then? How can I merge those changes?

Changes are part of software life, so they must be documented properly. Changes documentation should answer the following:

Who made the change? If something goes wrong you may identify who made what and the settle responsabilities.

What changes were made? You should keep track of what files were affected, what code lines were modified and what was changed in the logic.

When were those changes made? You’ll keep track of time invested on that change.

Why? Was it because of a user request?, a bug fix?, an enhancement?

If you work for a company answering these questions will prove to be a great way to justify your work. It will even make it easier for your colleagues to keep up with your coding style and logic.

Most developers use inline comments to document changes for example:


* author: Me

* date: October 25th 2009

* version: 1.0.1

* summary: User asked for the color to be changed from red to blue so the code changed from $color = “red”; to current


$color = “blue”;

That’s a nice way to keep track of changes but you’ll get to the point that one change requires a lot of file content modifications, folder creations, code logic changes, etc. which on large projects can be a real hell to keep track of. This just happened recently on my job.

We solved a lot of things by using a version control software. We tested it and finally decided to go for SVN or subversion. It’s pretty easy.

Even though projects creation and repositories administration were a mess at the begining because we wanted to limit access to developer groups only to their assigned projects. We kept SVN and installed USVN on ¬†top of it…. needles to say we are very very happy with the results.

We get to admin our repositories in a very simple way. Since USVN is developed in PHP Zend Framework and you get to modify the code we have made some customizations to it so it works as we want it to work.

One great thing we managed to do with SVN is have a strict control over our stage environment. Developers do a SVN commit which immediately updates a stage environment so changes are visible to QA.  Once QA approves a version we create a tag meaning its a new release which then goes to production.

That’s the main reason I’m posting this, I was the one responsible for implementing those automations and they do work.

How did I do this? Well it’s actually pretty simple. Once a SVN project is created you go into that project’s folder and go to the hooks subfolder. This is where the magic happens.

Though there are several types of hooks I only messed with the post-commit hook.

I granted execution permissions to post-commit file (remove the “.tmpl” part).

Modified the hook so its aware of some important paths and then coded a few lines so, for example, we got SVN to send an email reporting what changed, who did the changes and when was the code commited to project owner so he could keep track of his project.

SVN works for us right now and hooks are a charm. I’m pleased right now and so are my boss and my colleagues :D:D:D:D

I keep repeating to myself: Linux rocks, free software rocks and most of all I rock! hahahahahaha

Managing SVN repositories

Monday, November 16th, 2009

Now that I have an SVN server and I’m making extensive use of my repos I was asked by a friend to create a repo for a small project he has. Since the project was for the company he works for then aI became aware that I couldn’t just put up a repo and expect he didn’t take a look at my personal projects.

Since his repo would be on the same folder as mine I needed a way to keep his eyes away from my projects and still allow him full control of his own.

This is the easiest solution I came up to.

Under my repos folder I created a repo for my friend called “friendrepo”:

svnadmin create friendrepo

Then assigned the proper owner and group so my apache could handle it:

chown -R user:group friendrepo

Then I created a domain name for him to use in

Added the proper lines to httpd.ini to handle the domain, then added a folder to be pointed by that domain which looks something like this:


also changed the owner and group to those of my http server.

After that I created a soft link to my friends repo and voil√°!!!! It’s done!

Next I just added the users he asked me and there he goes! now he has a repo on my server and he can’t see my repos!!!

I’ll keep playing with SVN to see if there’s an easier way.

The SVN (Subversion) experience

Monday, November 9th, 2009

Wow! it’s been a while since the last time I posted a comment.

Mainly because of dev projects and other stuff that kept me busy and away from my blog.

While developing some stuff I found myself in real problems when a client asked me to change some code to the way it was a couple of months… WHAT?! all this work and now they wanted me to rollback! ok, that shouldn’t be difficult… well it took me almost a couple of weeks.

For the past months I’ve been involved in a couple of projects for a company called Impremedia. One thing I learned from them is keeping track of my code through their SVN server. When my client asked me to rollback a piece of code I wished I had an SVN to make my life simpler. After finishing the rollback I proposed myself to get an SVN server up and running ASAP and moving all my codes there.

After a couple of failed attemps Voila! my SVN server is up and running!

It took me a week to solve problems, edit and reedit conf files, start-stop-starting services and testing the server and finally it’s up. I’ll be moving all my source codes to it these week so I’m really reeeeaaaally happy!

What did I had to do?

Ok, It’s been a long way but I’ll resume all ¬†to the minimum.

Get acces to your box

Get httpd(apache) installed and running. Version 2.2 worked for me.

Install subversion.

Install dav_module and dav_svn_module.

Now it’s time for big decisions. Choose a folder where you would like to set your repository. Let’s suppose you want it under your web folder files (/var/www/html/) and you want to call it “svnrep”.

Go to /var/www/html/ and create the dir svnrep (mkdir svnrep).

Make it available for the httpd with a command that looks like this:

chown -R user:group /var/www/html/svnrep

Ok, that’s the repositories main directory. You noticed i said repositories? yes, this way you’ll be able to create many repositories in a blink.

Let’s enable the apache conf file.

Go ahead, open the httpd.conf file, get to the modules section and add the following:

LoadModule dav_module modules/

Now let’s configure apache to be aware of the repositories.

Go to your virtual host section and add this lines :

<VirtualHost *:80>

ServerName svn.mydomain

ServerAdmin user@mydomain

<Location />

DAV svn

SVNParentPath /var/www/html/svnrep



Once you added that “domain” restart your httpd.

If everything went fine your server will restart gracefully, the next thing you’ll want to do is creating a repository. Go ahead to /var/www/html/svnrep.

Assuming you want to create a repo called “myfirstproject” you’ll type:

svnadmin create myfirstproject

That will set the project files and configurations.

Then you’re done! next thing is importing your files to the repo and voil√°!

Please visit this link to get more detailed info about installation and configuration of SVN.