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

Reply via email to