As a software engineering student, many of the subjects of the career includes software development projects. And as every kind of project, they normally have: documentation, source code, configuration files, templates, etc.

At first being a newbie in software development practices I concluded after a while that I needed some sort of revision control for my projects, because all of them were presented to the teachers incrementally and progressively.

My first approach was to 'clone' my project and name it with some I meaningful name, something like:
  • bookstore_presentation_1
Was very common for me, if I read the name in the future is easy to deduce that this 'clone' is a snapshot of my project in the first presentation date.
But after a while I required to recover a 'clone' of an specific date, the only way to find it was to manually check the modification date of the files... pretty dumb.

Because of that I defined a naming convention for my snapshot copies, it was something like this:
  • project_presentationNumber_date(YY-MM-dd)_description
And I was kind of happy with this approach for some time, but after a a year my projects workspace got really nasty:
  • bookstore_pres1_08-02-10_initial
  • bookstore_pres2_08-02-12_basic_func
  • bookstore_pres3_08-03-01_simple_reports
  • bookstore_presFinal_08-03-10_final
  • bookstore_presFinal_08-03-10_improved
  • bookstore_presFinal_08-03-10_not_working
  • bookstore_presFinal_08-03-10_1h_before_presentation
Nasty, right?

But somehow I managed all my projects in this way for quite a while. Then I started working with teams; after a week of development it was pretty obvious that my naming convention was not working:
  • bookstore_pres1mine_08-08-05
  • bookstore_pres1jhonny_08-08-05
  • bookstore_pres1oscar_08-08-05
We had some torture hours trying to merge our project versions, but at the end we did it. To finish that project, we suffered as cargo horses for a complete semester, doing manual merges and dumb overrides.

The next year I started my thesis work and I didn't want for any reason to be involved with the same problems again (I was working with a fellow developer) and I started searching for a software tool that could help me to keep track of a project. After some minutes I have found CVS, I read all I could find and I got involved in Revision Control theories.



Then a teacher suggested me Subversion (CVS done right, as he said). I downloaded a copy of SVN red book and learned the basics commands and theory of the system. It took a whole afternoon to setup a local Subversion server and create a proper repository for the project, but I did it. My partner and I started working with an initial project structure and we were progressing really fast, but at the moment of merging our work, we had LOTS of problems and ended up with the decision of setting up a central repository for both of us, as is recommended in SVN book.



We created a project in Google Code with Subversion and we started working from zero again, and the result? It was a developer heaven, all our changes were being tracked and held in a reliable service. And yes we still had conflicts but Tortoise SVN did all the dirty work for us, we finished the project in 6 months with a dozen of releases (tags) and got our degree with a very good mark.

SVN taught us how to handle our source code, our documentation files and some other important files (images, scripts). It taught us which files should be tracked and which ones should be omitted. It gave us a tracking discipline, we learned the meaning of keywords like commit, update, revert, log, resolve, etc. 

Since then all our projects were under SVN and we were pretty happy. But then we started working with some fellows in other cities, 5 in total, and some of them didn't have an internet connection for more that an hour by day.

We required another approach, SVN was not enough this time, that is why we started working with Distributed Revision Control Systems, which is described in Revision control systems - Part 2.