[Adium-devl] Version Control - To change or not to change? THAT is the question!

[Alan Humpherys]

Since I have some strong feelings here, I decided it was time to "kick  
the Hornet's Nest" and write down my thoughts so I can come to a  
better understanding of the project direction.

Let me start by stating that my contributions to Adium thus far have  
been miniscule, so I have very little room to talk.  That being said,  
I hope to increase my level of involvement in the project and complete  
the AV work we have started out to accomplish.  I also have over 20  
years of experience in professional software development,  
architecture, and management, which has helped me weather the storms  
of whimsical trends in the ever-changing software development world.

Perhaps it is my lack of understanding about the DVCS (Distributed  
Version Control System) movement, but I am curious about the  
consistent chatter in the Adium mailing lists about moving to a DVCS.   
I have had some experience using Monotone with libpurple and have been  
reading about the various other systems (GIT, Bazaar) to attempt to  
come up to speed on this.

1. Why a DVCS?
After consideration on this topic, I have narrowed the differences  
between SVN and the various DVCS systems down to 2 of any consequence  
as they relate to Adium development.  There are certainly other  
differences between the implementation, features, and usability of any  
particular VCS, but these are the most important.

1.1. Disconnected Operation
It appears to me that the main impetus behind any DVCS is support for  
disconnected operation, to support development  in a situation where  
there is not access to a centralized repository.  I myself have had  
need of such a system, and see its appeal.  For example, 13 years ago,  
when I was developing the NetWare OS Kernel & JVM, it was commonplace  
that I was doing development on a plane, in a hotel room, or at a  
convention and did not have Internet access to do a checkin to our  
repository.  I just had to continue working and wait to do a checkin  
when I returned to the office. That was certainly not optimal, and I  
longed for a different solution.

However, the world has changed considerably in those 13 years, it has  
become so much more connected than it used to be.  You are now hard- 
pressed to find a hotel, or convention without Internet access.  When  
that is combined with the fact that we are working on a network  
application, I find myself hard-pressed to find any situation where an  
Adium developer is doing work and checking in the code when they do  
not have network access.  This would mean that they are doing a  
checkin without testing their code, which I find disturbing.

I believe that this removes disconnected operation from being a valid  
reason to switch away from SVN.

1.2. Merging Branches
Due to it's "multiple versions of the truth" model, where every  
developer has a copy of the repository, all of the DVCS systems have  
had to develop an extremely robust mechanism for creating and merging  
branches.  In effect, every check-in starts to have some of the  
characteristics of a branch and merge operation in those environments.

This is one of the areas where the DVCS models excel over SVN.  They  
are built with the notion of tracking changes to multiple branches so  
that they can be merged together at a later date with minimal manual  
effort.  This has been a common area of problems with any branching  
VCS for decades.

The good news is that both DVCS and SVN handle the branching operation  
well.  The operation is on the order of O(N), and it is inexpensive in  
the repository to make and track branches.

The unfortunate news is that SVN does not inherently aid in the  
process of merging changes from one branch to another.  This is  
especially apparent when there is a need to merge changes between  
branches multiple times (for long-living branches).  This capability  
is the key area of focus for SVN 1.5 development, and, as has been  
reported lately, that release has been delayed longer than expected as  
they attempt to work on the complex issues involved.

2. Should we change?
By my own arguments, DVCS systems have an advantage in merging, but is  
that reason enough to make the change?  Here are a number of other  
areas to consider before jumping to another VCS system "Because it's  
the wave of the future".

2.1. Tool Support
SVN has finally come into the realm of full support for the tools we  
use in Adium development.  It is a top-tier supported VCS for:

- Mac OS (included in 10.5)
- Trac
- XCode
- CIA

If we change to mtn, bzr, or git, the onus is upon us as a development  
team to integrate that new system with the tools we use on a day to  
day basis.  I would prefer that we use our limited development  
resources on new Adium features, rather than tool integration.

2.2. Product Maturity
It is something we take for granted, that the VCS is a reliable  
mechanism and that bugs in the system will not corrupt our source  
code.  I don't have any evidence that any one system is better than  
another in this area, but the fact that SVN has had longer to  
stabilize than the other systems gives me some level of comfort.

2.3. Size of User Community
The SVN community is quickly becoming the largest, and as a result,  
there is increased support for developer attention to improving SVN as  
well as integrating more development tools with it as a first-tier  
VCS.  Unless there is a critical mass for a platform, it will not gain  
that increased help from the community at large.  (I know this first  
hand as we struggled with the "Fire" project, which lost it's mind- 
space to Adium as the years went by.)

2.4. Ease of Use
Most of the VCS systems have adopted the CVS command set model, so  
someone familiar with that command set can get up to speed on the new  
tool quickly.  However, there are several items in DVCS systems which  
cause me some concern about the usability of DVCS systems over SVN.

2.4.1. Revision numbers
With SVN, there is a simple revision number that represents the state  
of the system at a given point.  In our case, this is a 5 digit number  
which grows incrementally over time.  Due to the restrictions of  
working in a distributed system, the DVCS systems typically adopt use  
of a date/time or MD5 hash, which is not as user friendly.

2.4.2. Local Repository
With a DVCS, you need to keep a local version of the repository on  
your machine.  The setup of such a local repository is an initial  
hurdle to ease of entry into using a system.  While disk space is  
getting cheaper all the time, I still found it inconvenient to find  
space for a few hundred megabytes (and growing) of local storage.   
With that local repository comes questions of backup and other  
maintenance that I would rather not have to deal with.

2.4.3. Two step checkout and checkin
With a DVCS, your normal checkout and checkin operations take place to  
your local repository, and that operation will appear very familiar to  
anyone acquainted with CVS or any of its descendants (like SVN).  The  
"wrinkle" comes in as you  have to synchronize your repository with  
one (or more) other repositories of other users.  As you do these  
synchronization operations, you have to exercise care to ensure that  
you do not unwittingly create a branch off of the main line you  
thought you were working on.  So now you have to do your checkin  
process twice....

2.4.3 Multiple Versions of the "Truth"
Because there are multiple self-standing repositories, there need to  
be conventions developed about how the project will determine which  
version of the truth to use in developing releases and reporting bugs.  
Most DVCS projects end up having one central repository serve as the  
master.  (Just like SVN does)

2.5 Facilitates Fragmentation
Because each developer has their own complete copy of the repository,  
they can very easily create their own project based upon the original,  
and have local development which is easily kept in sync with the  
original.  It just makes it easier for someone to create an "AdiumZ"  
because they were upset about something that "curmudgeonly old Alan"  
said.  While Open Source projects always allow for (and sometimes  
encourage) such fragmentation, just ask the average linux user what  
they think of having to choose between the ever fragmenting Linux  
distributions out there.

2.6 Distributed User Management
Inherent with having multiple repositories, comes the burden  
(potentially upon each developer) of managing the credentials for each  
user that is allowed to make changes to their repository.  While this  
can be minimized with a centralized "master" there is still some work  
involved in user management for each participant.

Lest my overt skepticism for the usefulness of present DVCS systems  
become apparent, I will throw out a few "bones" to the DVCS community.

2.7 Disaster Recovery
Because there are multiple repositories on many machines, it becomes  
easier to recover from the disaster of the centralized repository  
getting destroyed or being unavailable for long periods of time.  The  
group would just need to designate a new master repository from among  
the surviving copies and then move forward.

2.8 Cooperation with Pidgin
Because Adium has adopted libpurple for many of its IM protocol  
implementations, it places on onus on Adium developers to have to live  
in 2 different VCS systems. It would certainly be easier if a single  
VCS system were used for all of our development. In this case,  
adopting mtn would make development between Adium and libpurple easier.

3.0 My Conclusion
Sometimes the choice of development tools borders on a "religious  
war", and each person involved often holds deeply rooted beliefs that  
are difficult to change.  I myself resisted the switch from CVS to SVN  
for well over a year until I changed, and was eventually glad that I  
did.

However, as I look at the maturity and features of the current state  
of DVCS systems.  I find myself weighing the pro's and con's, but  
still find myself entrenched in the "It ain't broke, so don't fix it"  
camp for the Adium project.

SVN merging continues to be a burden, but there are enough concerns  
with a switch to DVCS, that my vote would be to stay on SVN for at  
least the next 6 months and then see what the landscape looks like.  I  
hold out hope that SVN 1.5 will be released, and will fix the merge  
deficiencies, and then it would make sense to stay with SVN even longer.

Alan   :: Puts on flame retardant suit ::
______
Alan Humpherys
Adium Development Team
alangh at adiumx.com
http://www.adiumx.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://adium.im/pipermail/devel_adium.im/attachments/20080101/b932979c/attachment-0001.html>