Source code control systems are close to religious topics for many people so
I want to avoid potential panic here. I understand that due to the
diversity of opinions within our developer community, it will be impossible
to reach any kind of consensus for any action. Even the default of no
action is controversial. :-) My goal here is to not debate the final
solution, but hopefully find some agreement so we can move a step forward,
and from that new position, we will be in a better position to discuss
future options.
So to start out, I think most of us agree that CVS is old and clunky and
there are a variety of better options available.
In addition, I am self hosting our master CVS repository which means that if
my machine breaks, I personally am on the hook to drop everything else and
do whatever it takes (ranging from hardware, to OS, to security, to whatever
...) to find and fix the problem before we can get our repository back
online. What if I happen to be on vacation or on a work trip or get hit by
the proverbial beer truck and then a problem develops with the server? To
add new developers, I personally need to manually create accounts, adjust
group membership, etc. again if I'm out of town or in the midst of some
crazy work deadline, there could be substantial delays. In addition, I have
a remote backup system in place for our CVS server, but that is another self
managed system and earlier this summer the backup system failed and all the
backup data was completely lost, leaving us with just a single primary copy
of the main repository until I could get the backup system back up and
running again (which it is now.) These are all things that could be
improved on and streamlined.
>From my perspective, these administrative issues are of equal importance to
discussing which specific version control system we might step to. All of
these things need to be considered together when determining a route
forward.
What I propose is that we migrate our self hosted CVS repository to
code.google.com and in the process convert to SVN.
1. This gives us "professional" management of the servers, regular
professional backups, and an automatec access control system for adding new
developers. Google has a tremendous amount of bandwidth and compute power
behind their systems, way more than I could ever offer on any self hosted
system. When something breaks on a google server, there is a pool of people
available and qualified to fix the problem. On any self hosted system (no
matter how well run) there is usually only one person who could jump in and
fix a potential problem.
2. We need to move away from CVS somehow. SVN is a big improvement (but
yes, I realize many of our developers think that going direct to some other
system will be an even bigger improvement.) Let me just offer that this
doesn't have to be the final destination. It may just be a step forward in
our journey. Please, please don't panic! I suspect that building a gateway
between SVN and other systems should be easier and more transparent than a
gateway between CVS and the other system given that SVN has more
capabilities than CVS.
3. I have prototyped the migration system with the SimGear repository and I
think it went pretty smoothly. Here is the link:
http://code.google.com/p/simgear/
4. code.google.com also offers a bug tracking system that we could begin to
use.
5. SourceForge offers many of these same things, however, it is awfully
slow. Google seems to be so much leaner and faster to do everything. After
navigating the google site for a while, it's really tough to go back and try
to plow through sourceforge which seems so much slower and clunkier in
comparison.
I think that when balancing both the administrative and technical aspects of
the issues, code.google.com offers a pretty good step forward and enables us
to cleanly step away from the old CVS-based, self-hosted system, so that is
what I would like to do.
It would be great if some of our developers could look through the simgear
projects site on code.google.com:
http://code.google.com/p/simgear/
Run through the process of checking out the code. Browse the changes,
browse the repository tree layout, browse the revision history etc. Does
the conversion process look like it worked well? Is everything there?
The one thing I don't yet have is support for a changelog mailing list, but
I suspect there are easy hooks for setting this up, and in addition, google
provides several RSS feeds for monitoring changes to different aspects of
the project (including source code changes.)
I think this will be a good step forward for our project. I think once the
transition is complete we'll be in a more solid position to be able to
debate possible further moves forward at that time. I do expect a diversity
of responses to this, but there's nothing wrong with diversity, right? :-)
Thanks,
Curt
--
Curtis Olson: http://baron.flightgear.org/~curt/
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
