Hi there, First of all, I want to thank Curt for starting this discussion. I'm very glad to hear that you are willing to improve the current situation.
Aside from the religious aspect of choosing a version control software (or whatever you name it), I want to say what should or can be improved in the current situation. As long as these things are (supposed to be) improved or resolved, any tool(s) work fine for me. 1) Response time Sometimes it takes very long for checking in or out the current repository. I've encountered time out and cannot check in or out. If moving the current repository to some other server(s) solve this problem, that's fine. 2) Permission problem Sometimes I've encountered errors in committing my local modification to the repository because of the lack of permission even one has a write access. When this happens, only Curt can fix the problem. This (including Curt's workload on this) must be improved. 3) Patches are sometimes not committed. I've seen some developers / contributers complain about their patches not being committed for a long time. Such incidents can affect the motivation of contributing to FG project. As a matter of fact, I, some time ago, posted a patch for configure.ac and Makefile.am so Mac users can build FG/SG using configure/make. However, it is not yet committed. If some tool can help in resolving such problem, that's very helpful. # I believe this is basically not a tool oriented problem, though. 4) No branches are made for making both release process and developing new features easier I believe that It is good to have a release branch while we are preparing for an official release since it doesn't prevent developers from committing a new features during the release process. I want to note that I don't say we need permanent development/release branches. You may have found that most (or all) of the issues above can be tool independent. I want to share these issues because it is very important to consider such issues when we choose a version control software, besides the pros and cons of each tool. Best, Tat p.s. Needless to say, a tool must work on Mac OS X ;-) On Sep 4, 2009, at 1:07 AM, Curtis Olson wrote: > On Thu, Sep 3, 2009 at 4:10 AM, Tim Moore <timo...@redhat.com> wrote: > 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. > > I only said that in attempt to deflect comments ahead of time from anyone who > would immediately take this up as a religious war and choose to push the > discussion in that direction. I really appreciate those that have responded > professionally. This really helps to advance this discussion in a positive > direction. > > 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. > > As long as this discussion is branching off in several directions, is it > worth discussing mercurial versus git? code.google.com supports mercurial > (hg). I have never used either. I've done a bit of googling, but much of > the information I've found has been dated, or not written in a way that > convinces me of the author's objectivity. > > 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. > > From what I've read, hg and git seem to be converging in similar directions > and each tool seems to be adding features to address their own weaknesses in > comparison with the other. > > Just as I'm writing this I am remembering an old grad school class project I > did with two other guys. We created a system based on CVS which would > automatically replicate a CVS repository across all participating systems. > This was back when we were all on dialup, and you usually dialed into a > bulletin board system, not an ISP. (Am I dating myself?) :-) So we set up > uucp bewteen our home machines and all the communication was done through > emails that were automatically intercepted and parsed on the receiving end. > The uucp subsystem took care of automatically dialing up the other computers > if there was something in the mail queue to be sent. There was a "token" for > each file and you had to have the token in order to do a commit. If you > didn't have the token, a token request was broadcast (over email/uucp) and > eventually it would be sent back to you and you could finalize the commit. > Believe it or not, this system actually worked and worked rather well to > maintain synchronization between distributed repository copies across a > non-internet connected collection of machines ... back in the days before DSL > and cable when it was actually difficult to get connected up to the > "internet". > > 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. > > I didn't do a cvs checkout, but just ran cvs2svn ... I wonder if it has an > option for this? Nothing is jumping out at me yet ... > > Regards, > > 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 ------------------------------------------------------------------------------ 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
