On 09/02/2009 05:55 PM, 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. :-) It is important to remember that, unlike a personal religious choice like emacs vs. vi, the outcome of this religious debate will affect many people's daily interaction with Flightgear. In this way I suppose the debate is more like a religious war :) To dismiss the debate as merely religious is to ignore real technical arguments. At the end of the day, of course, a choice must be made that will leave some people unhappy, but I hope we can arrive there by listening to all sides.
> > 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 ... > 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. Absolutely, and one would hope they would be orthogonal to the choice of VCS. In this day and age, especially in light of security considerations, big-time hosting should be left to professionals. If Flightgear gains in popularity as we all hope it does :), it will eventually be the target of a break-in or denial of service attack. I would much prefer to have that directed at code.google.com or some other hosting site than one of ours. > > 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, ... No argument here against code.google.com, except for the VCS support :) > > 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. It would be a pity to move from CVS and end up with SVN, even temporarily. First, let's be clear that "some other system" means Git. Several of us already use git for working with Flightgear. If anyone is using another system to interact with Flightgear's CVS, I'm not aware of it. There are at least two Git mirrors of of Flightgear and Simgear, so the conversion work has already been done. The advantages of distributed version control systems over centeralized ones like SVN are numerous, and I won't hash them out here unless it becomes necessary :) code.google.com does support Mercurial (also known as Hg), and I would urge you to consider that as a target instead of SVN. That said, I have not used Hg; from what I have read, git's support for branching, merging, and preserving the history of merges is stronger. These features were very useful in creating the 1.9.1 maintenance release, where new development was able to continue on a mainline branch and specific fixes could be pulled into the maint branch, or made on the maint branch and merged to the mainline. For me, lack of Git support would be a deal breaker for code.google.com. > > 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 agree that sourceforge has proved itself over the years to be a non-starter. > 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? I haven't checked it out yet, but I did browse it. I did notice that you imported the expanded CVS $Id$ strings into SVN, which is going to get very messy. At the least you should do the CVS checkout with -kk. > > 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 Tim ------------------------------------------------------------------------------ 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
