2007-06-21 10:46:21 - development meeting (aka bunker) mid-june - posted by Wu

Yesterday, we had a meeting to discuss some things about the ongoing projects from the company, aswell as some other interesting things about (this time) web development.

We usually call this meetings a bunker (we did bunkers even before Codigo23 exist), and I'll try to post from time to time some results about them.

This time we discussed mainly about two topics:

• - Migrating from CVS to Subversion
• - Taking decissions on how to approach new web development projects (keep working with the actual technologies, switch to another ones, etc)

The first point, the switch to Subversion is an important one. I've been using CVS for the last 2-3 years, and I'm happy with it. I didn't find any problem with it, it is stable, fast, mature, and allow me to manage all the projects i've been involved on. Now, with all the wars appeared lately about versioning control systems, and almost all people migrating to SVN (as most people call Subversion), I've taking a look at it.
I've read all the benefits on it's website, and I understand them, but one thing I don't understand is the way SVN handles revisions. Let me explain it with an example:

With CVS, we have a central repository, where code from all projects is stored. Inside that repository, we have an entry for each project, let's call them projectA and projectB. When those projects were added, all files inside them got revision 1.1. Both projects are python-based developments, and we have two files (modules) called projectA/src/moduleA.py and projectB/src/moduleB.py. Ok, on one point in time, moduleA.py is on revision 2.32, while moduleb.py is on revision 1.12. Now imagine that on that same point in time, development on projectB stops, but development in projectA continues until projectA/src/moduleA.py reaches revision 3.02. If in that very point we do some changes on projectB/src/moduleB.py, then it will result in that file getting revision 1.13. This is what, IMHO, is a logical approach, because each project is independent, but both projects are owned by the same company/group.

Well, the problem I found with SVN is that it doesn't work this way. With SVN, each commit to the repository apply a revision number to the files affected, but globally inside the repository. That means that if you do some changes in projectA/src/moduleA.py until it reaches revision 6278 (yes, SVN doesn't use the 1.0, 2.123 and the such revision numbers style), when after that you do a change on projectB/src/moduleB.py, it will reach revision 6279 (even if that file was on revision 12).
In the SVN book you can find a solution for that, put each project on a different repository. That leads us to another interesting discussion. This approach (IMHO) would be fine for really different projects where differents groups of developers work on, like some pieces of open source software like django. In such environment you will have a big number of developers working on that project, and it would be a good idea to put the project on an independent repository.

But what if we are talking about a little company, with different projects in which 3-5 people are involved?. For example, think about our beloved projects projectA and projectB. The first one is a python based development, while the other one is a website written in PHP. They are totally independent projects, but the people involved in both projects are the same. You will end with two separate repositories, and same people accessing them. I know that's not a problem, but I see it like an un-logical design.

Anyway, the final decission was to use SVN, mostly because of Trac (a webapp to access a SVN repository, with integrated wiki, ticketing system and much more). What we have to discuss now is how to set the repository(ies) layout, because if we put each project on a different repository, Trac will be aware of that, but will handle each project separately (which means separated wiki, tickets, etc), and that is not optimal for a little group of developers, like our case.

The second point was interesting (and important) too, because we talked about the direction to take in our next developments. I would like to switch from our current technology (PHP), to python, using something like modpython, Zope or some framework (Django), but there is still someone who prefers PHP.

So, yesterday, we talked about two web development frameworks mentioned a lot these days CakePHP and Django. We talked a lot about pros and cons, how the learning curve should be for each framework and, finally, we see some nice screencasts with examples.

We ended the bunker near 00:00, and then it happened... :D

We met at Puzzlemotor, a brand new company recently created (property of a close friend), which is located URL CODE NOT VALID (a place where a foundation helps young people to create new companies based on innovative ideas), and when we were going to leave the building, we reach the door that communicate the offices with the outer side of the building (the public one), and it was closed.
We were trapped! Fortunately, after jumping in front of the security camera near 15 minutes, a security guy appeared "hey guys!, so sorry, I didn't know you where in!". It was like being in a movie, even the power got disconnected and we were hanging around with only emergency lights on. When we finally got out, we can't stop laughing... :D

Post a reply