GS Design Just another developer blog

For me it all started when my VPS had an error and all my SVN repos were lost. Plus even though i had purchased a backup system from the hosting company that was suppose to do a full server backup automatic and incrementally, i only had a backup from 20 days earlier because the system failed at that point in time and didnt run since.

But enough with my problems, at that point i decided to make a copy of my repos from the remote server to my local machine.
And i would commit into the local one and it should automaticly sync to the remote one. Plus it would need to do this both ways and in real time since i had some external people commiting in the remote server. Easier said then done i camed to find out.

The reasons why

Well for me there are 3 main reasons:
1. as a backup system ( dont want to be put in the 20 days old backup situation again )
2. for faster commits and updates
3. independent of the internet connection ( it hasnt failed in quite a while, but just in case, or for the times its a bit slow )

The alternatives

It seems that this topic is a bit popular, and there are a few places on the internet where people are interested in this. You can check out this question on stackoverflow for one.

1. Git-SVN
This is one alternative that a lot of people have been recommended. The benefits they are you get the best out of both worlds, you can still use the Subversion in the main repo, but you get the power of GIT for your local copy.
Although this sounds very cool, i am more of a GUI guy and really enjoy the subversion integration in my IDE ( Netbeans ) so i would have to pass this options.

2. SVK

svk is a decentralized version control system built with the robust Subversion filesystem. It supports repository mirroring, disconnected operation, history-sensitive merging, and integrates with other version control systems, as well as popular visual merge tools.

At first i read this article about SVK and it seemed to be what i was looking for. But after playing with it for a while i saw that i would need to have a single repo where all my comits would go and that would be synced to several outside repos. But i was looking for a way to have the exact replica of what it is on the remote server so in the case of a failure i could restore them from my backup.

If you are still interested in this you can also read this and this.

3. svnsync + webdav proxy
I knew about svnsync but it only supports read-only copies of your repo. But after reading a small comment on stackoverflow i started looking and find out you can have read-write copies using svnsync and webdav proxy.
What is basicly happening is that your local copy handles the read operations and it forwards the commits to the main repo.

There are a few tricky parts on this solution, that involve the locks and updating of all the replicas of the main repo. This are done by a series of hooks in the main repo.
If youre interested in this solution you can find information about implementing it in this articles:
Subversion transparent proxy with svnsync + webdav proxy
subversion diy write through proxy
Subversion on-the-fly replication

conclusion

Honestly i don’t have one yet , but i plant to try using svnsnyc and see how that goes.
I hope you got a big picture of what your options are and now you can decide what suits you best.

Cheers

First of all, a little heads up, this is not a perfect solution, and there isnt one outhere.
There is only the best solution for you at this point in time.

This structure was thought by Victor Stanciu and me after a lot of debating and googling, and so far we are happy with it.

The debate on how a repo is structured is quite a big one, and you can see this by looking on the talks on the matter for example on stackoverflow.com

Considerations

The things we took into consideration is that we are working on mostly small projects ( all of them are web projects ), which are quickly developed and sent into production.
Also there were projects coming from an older client so we wanted a way to group projects from same companies.

Solution

So after we thought all of this through, we decided the best way to go is to have a repository setuped for each project.
The reason we wanted to do this, is because it could trac the revision number more easily and also we could setup the issue-tracker more better. We use TRAC witch only tracs one repo at a time at it would have been weird to have tickets or components from different projects.

The layout would be kind of like this :

/svn
-----/conf
-----/repos
----------/company1
--------------/project1
------------------/tags
------------------/branches
------------------/trunk
----------------------/web
----------/company2
--------------/project1
------------------/tags
------------------/branches
------------------/trunk
----------------------/web


The conf folder is where we keep the configuration files included by apache for serving the repo with mod_dav.

We create another folder web in trunk ad the main project is in there. This is because you might want to have something else in trunk also. Like specification documents.

This is all folks.
Cheers

IF you just got into versioning your code then you are probably really happy with your acomplishment.
But do you have your database versioned ? This is the questioned asked in this here by Jeff Atwood and also asked by a lot of users on stackoverflow.

After reading a lot on this topic i decided on a strategy on how to keep my database under version control.
As a warning it isn’t the most easy strategy and it really takes some discipline from all the developers.
Read the rest of this entry »

Today i finally decided to go ahead with installing subversion, after a bit of reading i opened a ssh session and input :

[root@servername ~]# yum install subversion

But to my surprise i got an error

Error: Missing Dependency: perl(URI) >= 1.17 is needed by package subversion

After a bit of googling i managed to find a solution on a forum and i thought to post it here, maybe other will find it faster

First we need to download the perl(URI) with version greater than 1.17 using the following command.

wget http://yum.trixbox.org/centos/5/RPMS/perl-URI-1.35-3.noarch.rpm

Then to install the perl package :

rpm -i perl-URI-1.35-3.noarch.rpm

That is it, you can now install and configure subversion as normal.

Cheers.