Hi Curt
My only concern with SVN is that it stores every file twice in the local
file system, so it's not ideal for the 'data' portion of FlightGear. For
example, right now a complete checkout of Aircraft is ~ 2 GB, and it
would double overnight.
I know, disk space is cheap in these days, but the double-write also
results in slower checkouts.
In other words, I think we should import FlightGear as well into
code.google.com and see if we are happy with the performance before jumping.
Apart from this concern, I've used CVS, SVN and GIT and I'm not
religious about the choice.
In the end, any tool will work as long as it's:
- fast
- easy to use
- well integrated with other tools like bug tracking SW <----- and
this is very important IMHO
(you have bugs referring to check-ins, check-ins referring to bugs,
RSS feeds of changes, etc ...)
Tom
Curtis Olson wrote:
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 <http://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 <http://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 <http://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>:
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/
<http://baron.flightgear.org/%7Ecurt/>
------------------------------------------------------------------------
------------------------------------------------------------------------------
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
------------------------------------------------------------------------------
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
