Re: [Flightgear-devel] Source code control systems

[Olaf Flebbe]

Hi,

I did some experiments both with hg and git, and collecting responses.

IMHO there is no real technical point to prefer one of DVCS'es.

* Tim Moore told us gitorious have push too.
* msysgit is a little bit better integrated in Windows -- for instance 
simpler file name mapping.
* with tortoisegit even a GUI exist
* At mapserv a fgdata a git repository of data exists for some time.
   (The bare repository itself is a little bit smaller than the CVS 
checkout itself)
* Checkout of fgdata worked flawless with Windows. Updating fgdata is 
much faster than CVS

Additionaly:

* hg can work with fgdata, too: Its repository is marginaly larger 
compared to git
* I had no time to actually upload fgdata-hg to somewhere else
* (tortoisehg exists)

Given the existing infrastructure for git services, no objections from 
me against git (any more).

We should step further and discuss on how a transition can be made. BTW 
I would vote for the gitorious system.

Greetings
Olaf

--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Source code control systems

[Pete Morgan]

So what would the "source  tree" look like to you as a developer and pilot
eg
hanger/boeing/**



Pablo Rogina wrote:
> Pete Morgan wrote:
>
> > I do like the way qt uses it with merge requests. a lot of them to do
> > with documentation corrections, as well as minor touches to code.
>
> I was following this thread since I'm interested about opinions and 
> thoughts about version control systems, from a software engineering 
> perspective.
>
> I don't know why it's really taking so long to make a decision about 
> the tool to use (name it: git, hg, svn, etc.). I do personally prefer 
> git and the DVCS proposed by it.
>
> And I would choose gitorious as the repository for that. Could Nokia 
> be so terribly wrong to trust one of its latest adquisitions, Qt 
> source code, to that repository without having thought it very carefully?
> And yes, they have set up a very good contribution scheme through the 
> merge requests.
>
> So at this point I cannot understand why FlightGear proyect could be 
> sooo different from Qt, which have several full time developers making 
> lots of changes, additions and so on, plus lots of contributions from 
> external resources. And everything is fine resting on git and gitorious.
>
> Regarding svn externals, that is a great thing from SVN and, even if I 
> didn't use it so far, it seems that svn externals can be mimic in git 
> by means of git's submodules
>
> http://panthersoftware.com/articles/view/3/svn-s-svn-externals-to-git-s-submodule-for-rails-plugins
>
> Just my 2 cents...
>
> Pablo
> 
>
> --
> Come build with us! The BlackBerry® Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay 
> ahead of the curve. Join us from November 9-12, 2009. Register now!
> http://p.sf.net/sfu/devconf
> 
>
> ___
> Flightgear-devel mailing list
> Flightgear-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
>   


--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Source code control systems

[Pablo Rogina]

Pete Morgan wrote:

> I do like the way qt uses it with merge requests. a lot of them to do
> with documentation corrections, as well as minor touches to code.

I was following this thread since I'm interested about opinions and thoughts
about version control systems, from a software engineering perspective.

I don't know why it's really taking so long to make a decision about the
tool to use (name it: git, hg, svn, etc.). I do personally prefer git and
the DVCS proposed by it.

And I would choose gitorious as the repository for that. Could Nokia be so
terribly wrong to trust one of its latest adquisitions, Qt source code, to
that repository without having thought it very carefully?
And yes, they have set up a very good contribution scheme through the merge
requests.

So at this point I cannot understand why FlightGear proyect could be sooo
different from Qt, which have several full time developers making lots of
changes, additions and so on, plus lots of contributions from external
resources. And everything is fine resting on git and gitorious.

Regarding svn externals, that is a great thing from SVN and, even if I
didn't use it so far, it seems that svn externals can be mimic in git by
means of git's submodules

http://panthersoftware.com/articles/view/3/svn-s-svn-externals-to-git-s-submodule-for-rails-plugins

Just my 2 cents...

Pablo
--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Source code control systems

[Vivian Meazza]

Tim wrote

> -Original Message-
> From: Tim Moore [mailto:timo...@redhat.com]
> Sent: 29 September 2009 09:26
> To: FlightGear developers discussions
> Subject: Re: [Flightgear-devel] Source code control systems
> 
> On 09/29/2009 08:54 AM, Stefan Seifert wrote:
> > On Tuesday, 29. September 2009, Olaf Flebbe wrote:
> >
> >> Let me talk from the Windows perspective:
> >>
> >> git seems to work best with msysgit. Entrance barrier: You need to know
> >> UNIX shell. (After trying out I would recommend the msysgit rather the
> >> cygwin). Documentation of msysgit is almost non existing and sometimes
> >> misleading. But: It works.
> >
> > Has anyone ever tried TortoiseGit? http://code.google.com/p/tortoisegit/
> > Seems to be a nice and working git client for Windows and I can't
> remember it
> > being mentioned on this list.
> >
> >> svn implements push. hg can implement both. git seems more designed for
> >>   pull (linux kernel process), but can implement push too (samba git
> for
> >> instance, mapserv?).
> >
> > I've only ever used git in push style so I can confirm, that this does
> work as
> > well as svn.
> 
> I use git in many push style projects too.
> 
> The gitorious repos are being run in the pull style right now. No
> one has asked for commit rights to it, and the only official source of
> patches
> is CVS... but as I have said elsewhere, these repos are not a direct
> mirror of
> CVS. I've been maintaining a "master" branch which is supposed to be
> stable,
> using somewhat arbitrary and vague criteria :)
> 


I use Tortoise git - it isn't bomb proof, but then neither is mysysgit.
Cygwin git is pretty good, but of course is only command line. I'm used to
that, way back that was all we had for CVS too.

I would back up Olaf's observations. I had a clone get stuck the other day
with a bad update, the only way out was to delete it and start over. Which
isn't as bad as it sounds, because git is quite fast.

I also use Tortoise SVN. Doesn't seem to offer any advantage over CVS.
Indeed neither does git, except speed, but then it seems a bit flakey too.

Vivian



--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Source code control systems

[Pete Morgan]

Tim Moore wrote:
> The gitorious repos are being run in the pull style right now. No
> one has asked for commit rights to it, and the only official source of patches
> is CVS... but as I have said elsewhere, these repos are not a direct mirror of
> CVS. I've been maintaining a "master" branch which is supposed to be stable,
> using somewhat arbitrary and vague criteria :)
>   
Can I have commit rights ie push to gitourious. As a test with minor 
patches.

I do like the way qt uses it with merge requests. a lot of them to do 
with documentation corrections, as well as minor touches to code.

As far as I see it as a new git user,  this would allow me to push my 
patches as merge requests, which can then be reviewed  into "master" or 
HEAD or trunk or whatever the latest bleeding edge version is.

Indeed I cant wait for the /data to be on gitorious, because that is the 
big challenge.. ie tweaking terrain and aircraft.

So we do we go from here ?
is the idea to create one gigantic GIT with
source/
hanger/
 aircraft = git.extenrals
airports

One of the things that's wonderful about svn is externals..

pete
> Tim
>
>   


--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Source code control systems

[Tim Moore]

On 09/29/2009 08:54 AM, Stefan Seifert wrote:
> On Tuesday, 29. September 2009, Olaf Flebbe wrote:
> 
>> Let me talk from the Windows perspective:
>>
>> git seems to work best with msysgit. Entrance barrier: You need to know
>> UNIX shell. (After trying out I would recommend the msysgit rather the
>> cygwin). Documentation of msysgit is almost non existing and sometimes
>> misleading. But: It works.
> 
> Has anyone ever tried TortoiseGit? http://code.google.com/p/tortoisegit/
> Seems to be a nice and working git client for Windows and I can't remember it 
> being mentioned on this list.
> 
>> svn implements push. hg can implement both. git seems more designed for
>>   pull (linux kernel process), but can implement push too (samba git for
>> instance, mapserv?).
> 
> I've only ever used git in push style so I can confirm, that this does work 
> as 
> well as svn.

I use git in many push style projects too.

The gitorious repos are being run in the pull style right now. No
one has asked for commit rights to it, and the only official source of patches
is CVS... but as I have said elsewhere, these repos are not a direct mirror of
CVS. I've been maintaining a "master" branch which is supposed to be stable,
using somewhat arbitrary and vague criteria :)

Tim

--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Source code control systems

[Stefan Seifert]

On Tuesday, 29. September 2009, Olaf Flebbe wrote:

> Let me talk from the Windows perspective:
>
> git seems to work best with msysgit. Entrance barrier: You need to know
> UNIX shell. (After trying out I would recommend the msysgit rather the
> cygwin). Documentation of msysgit is almost non existing and sometimes
> misleading. But: It works.

Has anyone ever tried TortoiseGit? http://code.google.com/p/tortoisegit/
Seems to be a nice and working git client for Windows and I can't remember it 
being mentioned on this list.

> svn implements push. hg can implement both. git seems more designed for
>   pull (linux kernel process), but can implement push too (samba git for
> instance, mapserv?).

I've only ever used git in push style so I can confirm, that this does work as 
well as svn.

Stefan

--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Source code control systems

[Olaf Flebbe]

James A. Treacy schrieb:
> On Mon, Sep 28, 2009 at 07:25:33PM -0600, Ron Jensen wrote:
>> My own, personal opinion is SVN is worse than CVS.  I see no advantage
>> to moving there first.
> 
> Could you elaborate on this? This discussion needs more facts so that
> a rational decision can be reached.
> 

Let me talk from the Windows perspective:

CVS is working best with cygwin, this is an entrance barrier, since you 
need to now UNIX shell. The directory mapping UNIX<->Windows is weird 
for the inexperienced.

git seems to work best with msysgit. Entrance barrier: You need to know 
UNIX shell. (After trying out I would recommend the msysgit rather the 
cygwin). Documentation of msysgit is almost non existing and sometimes 
misleading. But: It works.
There are existing repositories even one for fgdata. Haven't time enough 
to check it out in windows and doublecheck.

svn implementations for Windows are excellent (several to choose from) 
and lean.

hg implementation for Windows is excellent and lean. I am almost through 
converting fgdata to a mercurial repository and uploading it to google, 
in order to double check out if it works good with this kind of data.

The hg-git gateway  (Working with hg on git repositories 
http://hg-git.github.com/) died while accessing gitorious, 
unfortunately. No option, I guess.


[ I made an error when looking at CR/LF issues with *.vcproj. git and hg 
repositories are o.k. ]


For a DVCS:

Iff hg does work with a fgdata repo in reasonable time and space I would 
opt for hg as a DVCS, since it has the lowest entry barriers for 
developers running Windows. Otherwise choose (msys)git.


svn would be a benefit as a VCS for Windows, since cygwin isn't strictly 
needed any more.


 From a Management perspective:

gitorious seems to implement a pull style DVCS, if I did understood it 
correctly. Someone has to pull changesets from other git repositories to 
manage the official FlightGear distribution. I would call it wasting 
developer resources. Please correct me if I am wrong.

The Flightgear cvs was a push style repository, where selected 
developers can work on (at selected parts).

svn implements push. hg can implement both. git seems more designed for 
  pull (linux kernel process), but can implement push too (samba git for 
instance, mapserv?).

[More on this topic for instance in 
http://hgbook.red-bean.com/read/collaborating-with-other-people.html]

So, please wait for the hg experiments to finish.

Greetings,
   Olaf

--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Source code control systems

[James A. Treacy]

On Mon, Sep 28, 2009 at 07:25:33PM -0600, Ron Jensen wrote:
> My own, personal opinion is SVN is worse than CVS.  I see no advantage
> to moving there first.

Could you elaborate on this? This discussion needs more facts so that
a rational decision can be reached.

-- 
James Treacy
tre...@debian.org

--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Source code control systems

[Ron Jensen]

On Mon, 2009-09-28 at 23:58 +0100, Pete Morgan wrote:
> As an observer..
> 
> This is a long thread with no conclusions, but maybe one.
> 
> The one firm conclusion is to get off CVS at least.
> 
> So i dont see why it can't be  first be moved to svn which is tried and 
> tested, supported on windows as the first step.
> 
> pete

My own, personal opinion is SVN is worse than CVS.  I see no advantage
to moving there first.

Thanks,

Ron


--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Source code control systems

[Pete Morgan]

As an observer..

This is a long thread with no conclusions, but maybe one.

The one firm conclusion is to get off CVS at least.

So i dont see why it can't be  first be moved to svn which is tried and 
tested, supported on windows as the first step.

pete



--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Source code control systems

[Timothy Moore]

On 09/26/2009 10:50 PM, Olaf Flebbe wrote:
> Hi,
> 
> I do not have write permissions to any of the hg or git reprositories...
> 
> So I can only check repositories out, which works flawless with git and 
> hg, no surprise.
> 
I see that you've cloned the gitorious repo; if you still need write access
to the originals for your testing, let me know.

> BUT:
> 
> * Both the hg https://possible-little-test.googlecode.com/hg
> and the gitorious repositories have corrupted the VC90 Project files. 
> They should to be CR LF terminated files as they are in the CVS.
> (For instance projects/VC90/FlightGear.sln: A double click does only 
> work with CR LF endings).
> 

I can't speak for Hg, but this is probably an artifact of the CVS->git 
conversion
and the fact that it was done on Linux. By the by, here on Linux I don't
see CR LF in FlightGear.sln.
> 
> 
> * The real thing would be FlightGear "data"!
If in fact it is desirable to host the whole data collection in one repo...

Tim

--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Source code control systems

[Tim Moore]

On 09/26/2009 10:50 PM, Olaf Flebbe wrote:
> Hi,
> 
> I do not have write permissions to any of the hg or git reprositories...
> 
> So I can only check repositories out, which works flawless with git and 
> hg, no surprise.
> 
I see that you've cloned the gitorious repo; if you still need write access
to the originals for your testing, let me know.

> BUT:
> 
> * Both the hg https://possible-little-test.googlecode.com/hg
> and the gitorious repositories have corrupted the VC90 Project files. 
> They should to be CR LF terminated files as they are in the CVS.
> (For instance projects/VC90/FlightGear.sln: A double click does only 
> work with CR LF endings).
> 

I can't speak for Hg, but this is probably an artifact of the CVS->git 
conversion
and the fact that it was done on Linux. By the by, here on Linux I don't
see CR LF in FlightGear.sln.
> 
> 
> * The real thing would be FlightGear "data"!
If in fact it is desirable to host the whole data collection in one repo...

Tim

--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Source code control systems

[Tim Moore]

On 09/24/2009 10:56 PM, Olaf Flebbe wrote:

> 
> 2) From the homepage:
> "So you do not want to help? Then there is nothing to see here, please 
> move along." this is not friendly for the casual user of some kind of 
> middleware when I have other options.

This is in the section "How Not to Participate." It sounds to me like
a joke, perhaps rendered unfunny by several language barriers.

Tim

--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Source code control systems

[Alex Perry]

On Sat, Sep 26, 2009 at 1:50 PM, Olaf Flebbe  wrote:
> I do not have write permissions to any of the hg or git reprositories...

Yeah.  I don't think there is a way I can find out everybody's google
accounts from their email traffic.  To try to speed this up, I've put
up a quick web form:
https://spreadsheets.google.com/viewform?formkey=dDZYb1RvYkpVRWhST2hhVFltWDQxNnc6MA
But, if you prefer, feel free to just email me or Tom directly.

> * Both the hg https://possible-little-test.googlecode.com/hg
> and the gitorious repositories have corrupted the VC90 Project files.
> They should to be CR LF terminated files as they are in the CVS.
> (For instance projects/VC90/FlightGear.sln: A double click does only
> work with CR LF endings).

If the repositories are wrong in exactly the same way, that likely
means Tom made a mistake during the conversion step because I just
uploaded his repository.  Perhaps you could work with him to figure
out what it was?  We can reload the Code test repository (don't know
about the Bitbucket one) as soon as we've got a fix.

> * The real thing would be FlightGear "data"!

Yes.  Let us figure out how to get binary data into Hg correctly first ...

> Greetings,
>   Olaf

--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Source code control systems

[AJ MacLeod]

On Saturday 26 September 2009 21:50:30 Olaf Flebbe wrote:

> * The real thing would be FlightGear "data"!

I'm sure I'm not the only person who has been happily using the mapserver git 
repo for FG data for quite some time now (on Linux)...

Cheers,

AJ

--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Source code control systems

[Olaf Flebbe]

Hi,

I do not have write permissions to any of the hg or git reprositories...

So I can only check repositories out, which works flawless with git and 
hg, no surprise.

BUT:

* Both the hg https://possible-little-test.googlecode.com/hg
and the gitorious repositories have corrupted the VC90 Project files. 
They should to be CR LF terminated files as they are in the CVS.
(For instance projects/VC90/FlightGear.sln: A double click does only 
work with CR LF endings).



* The real thing would be FlightGear "data"!

Greetings,
   Olaf

--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Source code control systems

[Alex Perry]

On Fri, Sep 25, 2009 at 10:05 PM, Alex Perry  wrote:
> On Fri, Sep 25, 2009 at 9:46 PM, Tom P  wrote:
>> Hi
>>
>> I've tried to push a Mercurial test repository (FlightGear converted from
>> CVS) to code.google.com for a few hours, without success.
>> It aborts regularly with the following message:
>> searching for changes
>> abort: error: Connection timed out
>>
>> After digging a bit, it looks like I stumbled on a known issue.. ooops!!
>>   http://code.google.com/p/support/issues/detail?id=2716
>
> Could you put the exact repository you're trying to push somewhere
> where I can get at it?  Feel free to try sending a tarball to me
> directly by email on the off chance it fits through the gateways.

The exact tarball Tom sent over uploaded fine for me over home broadband:
http://code.google.com/p/support/issues/detail?id=2716#c22

Therefore, in addition to the bitbucket repository Tom mentioned
below, we also have:
hg clone https://possible-little-test.googlecode.com/hg FlightGear-0.9

Both seem to work for me, so it'd probably be a good idea to do the
Mercurial client tool usability testing against both repositories in
case there is a difference we care about.

>> So, next I tried on bitbucket.org, which is the mainstream Hg hosting site,
>> and gladly it worked as expected.
>> The complete FlightGear repo got pushed in 11minutes,
>> and for your reference, is available here:
>>   http://bitbucket.org/tomp/fg-test/
>>
>> The only thing that I don't like about bitbucket.org is that repositories
>> are not organized by project, like on gitorious.org, but only per person.
>> It makes sense for an anarchic... err, deeply distributed development model,
>> but could get confusing quickly if we want to stick to a semi-centralized
>> one.
>
> I don't think that's a factor for people trying out the client side
> tools for Hg to see whether they suitably usable.
>
>> What now?
>> I'll try to break TortoiseGit on the Windows side of things.
>> Somehow I'm not convinced that Qt would use Git if it was so broken on
>> Windows, but it's just me.
>>
>> Have fun!
>>
>>   Tom
>>
>>
>> On Fri, Sep 25, 2009 at 12:01 AM, Erik Hofman  wrote:
>>>
>>> Olaf Flebbe wrote:
>>> > Windows Implementations:
>>> >
>>> > git can be tedious to use on Windows: I had big problems working on a
>>> > project mixing up git repositories on linux pushed and pulled by a
>>> > windows git via samba. git at some point complained about non existing
>>> > differences: Somehow line ending issues emerged, or the object store got
>>> > corrupted. I had no chance to look deeper into details. The stable git
>>> > command on Windows needs cygwin, which is not a minimal invasive
>>> > installation. (I wouldn't recommend the msys/mingw installation at this
>>> > point.)
>>> >
>>> > The hg (mercurial) Implementation of Windows is very lean, because no
>>> > POSIX emulation layer is needed. I (luckily?) had no problems with
>>> > respect to line endings with hg.
>>>
>>> This alone leaves me to rethink about git in favor of hg. Either are
>>> fine with me in the end but I would hate to lose Windows developers over
>>> this.
>>>
>>> Erik
>>>
>>>
>>> --
>>> Come build with us! The BlackBerry® Developer Conference in SF, CA
>>> is the only developer event you need to attend this year. Jumpstart your
>>> developing skills, take BlackBerry mobile applications to market and stay
>>> ahead of the curve. Join us from November 9-12, 2009. Register
>>> now!
>>> http://p.sf.net/sfu/devconf
>>> ___
>>> Flightgear-devel mailing list
>>> Flightgear-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
>>
>>
>> --
>> Come build with us! The BlackBerry® Developer Conference in SF, CA
>> is the only developer event you need to attend this year. Jumpstart your
>> developing skills, take BlackBerry mobile applications to market and stay
>> ahead of the curve. Join us from November 9-12, 2009. Register now!
>> http://p.sf.net/sfu/devconf
>> ___
>> Flightgear-devel mailing list
>> Flightgear-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
>>
>>
>

--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Source code control systems

[Alex Perry]

On Fri, Sep 25, 2009 at 9:46 PM, Tom P  wrote:
> Hi
>
> I've tried to push a Mercurial test repository (FlightGear converted from
> CVS) to code.google.com for a few hours, without success.
> It aborts regularly with the following message:
> searching for changes
> abort: error: Connection timed out
>
> After digging a bit, it looks like I stumbled on a known issue.. ooops!!
>   http://code.google.com/p/support/issues/detail?id=2716

Could you put the exact repository you're trying to push somewhere
where I can get at it?  Feel free to try sending a tarball to me
directly by email on the off chance it fits through the gateways.

> So, next I tried on bitbucket.org, which is the mainstream Hg hosting site,
> and gladly it worked as expected.
> The complete FlightGear repo got pushed in 11minutes,
> and for your reference, is available here:
>   http://bitbucket.org/tomp/fg-test/
>
> The only thing that I don't like about bitbucket.org is that repositories
> are not organized by project, like on gitorious.org, but only per person.
> It makes sense for an anarchic... err, deeply distributed development model,
> but could get confusing quickly if we want to stick to a semi-centralized
> one.

I don't think that's a factor for people trying out the client side
tools for Hg to see whether they suitably usable.

> What now?
> I'll try to break TortoiseGit on the Windows side of things.
> Somehow I'm not convinced that Qt would use Git if it was so broken on
> Windows, but it's just me.
>
> Have fun!
>
>   Tom
>
>
> On Fri, Sep 25, 2009 at 12:01 AM, Erik Hofman  wrote:
>>
>> Olaf Flebbe wrote:
>> > Windows Implementations:
>> >
>> > git can be tedious to use on Windows: I had big problems working on a
>> > project mixing up git repositories on linux pushed and pulled by a
>> > windows git via samba. git at some point complained about non existing
>> > differences: Somehow line ending issues emerged, or the object store got
>> > corrupted. I had no chance to look deeper into details. The stable git
>> > command on Windows needs cygwin, which is not a minimal invasive
>> > installation. (I wouldn't recommend the msys/mingw installation at this
>> > point.)
>> >
>> > The hg (mercurial) Implementation of Windows is very lean, because no
>> > POSIX emulation layer is needed. I (luckily?) had no problems with
>> > respect to line endings with hg.
>>
>> This alone leaves me to rethink about git in favor of hg. Either are
>> fine with me in the end but I would hate to lose Windows developers over
>> this.
>>
>> Erik
>>
>>
>> --
>> Come build with us! The BlackBerry® Developer Conference in SF, CA
>> is the only developer event you need to attend this year. Jumpstart your
>> developing skills, take BlackBerry mobile applications to market and stay
>> ahead of the curve. Join us from November 9-12, 2009. Register
>> now!
>> http://p.sf.net/sfu/devconf
>> ___
>> Flightgear-devel mailing list
>> Flightgear-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
>
>
> --
> Come build with us! The BlackBerry® Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9-12, 2009. Register now!
> http://p.sf.net/sfu/devconf
> ___
> Flightgear-devel mailing list
> Flightgear-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
>
>

--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Source code control systems

[Tom P]

Hi

I've tried to push a Mercurial test repository (FlightGear converted from
CVS) to code.google.com for a few hours, without success.
It aborts regularly with the following message:
searching for changes
abort: error: Connection timed out

After digging a bit, it looks like I stumbled on a known issue.. ooops!!
  http://code.google.com/p/support/issues/detail?id=2716


So, next I tried on bitbucket.org, which is the mainstream Hg hosting site,
and gladly it worked as expected.
The complete FlightGear repo got pushed in 11minutes,
and for your reference, is available here:
  http://bitbucket.org/tomp/fg-test/

The only thing that I don't like about bitbucket.org is that repositories
are not organized by project, like on gitorious.org, but only per person.
It makes sense for an anarchic... err, deeply distributed development model,
but could get confusing quickly if we want to stick to a semi-centralized
one.

What now?
I'll try to break TortoiseGit on the Windows side of things.
Somehow I'm not convinced that Qt would use Git if it was so broken on
Windows, but it's just me.

Have fun!

  Tom


On Fri, Sep 25, 2009 at 12:01 AM, Erik Hofman  wrote:

>
> Olaf Flebbe wrote:
> > Windows Implementations:
> >
> > git can be tedious to use on Windows: I had big problems working on a
> > project mixing up git repositories on linux pushed and pulled by a
> > windows git via samba. git at some point complained about non existing
> > differences: Somehow line ending issues emerged, or the object store got
> > corrupted. I had no chance to look deeper into details. The stable git
> > command on Windows needs cygwin, which is not a minimal invasive
> > installation. (I wouldn't recommend the msys/mingw installation at this
> > point.)
> >
> > The hg (mercurial) Implementation of Windows is very lean, because no
> > POSIX emulation layer is needed. I (luckily?) had no problems with
> > respect to line endings with hg.
>
> This alone leaves me to rethink about git in favor of hg. Either are
> fine with me in the end but I would hate to lose Windows developers over
> this.
>
> Erik
>
>
> --
> Come build with us! The BlackBerry® Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9-12, 2009. Register now!
> http://p.sf.net/sfu/devconf
> ___
> Flightgear-devel mailing list
> Flightgear-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
>
--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Source code control systems

[Erik Hofman]

Olaf Flebbe wrote:
> Windows Implementations:
> 
> git can be tedious to use on Windows: I had big problems working on a 
> project mixing up git repositories on linux pushed and pulled by a 
> windows git via samba. git at some point complained about non existing 
> differences: Somehow line ending issues emerged, or the object store got 
> corrupted. I had no chance to look deeper into details. The stable git 
> command on Windows needs cygwin, which is not a minimal invasive 
> installation. (I wouldn't recommend the msys/mingw installation at this 
> point.)
> 
> The hg (mercurial) Implementation of Windows is very lean, because no 
> POSIX emulation layer is needed. I (luckily?) had no problems with 
> respect to line endings with hg.

This alone leaves me to rethink about git in favor of hg. Either are 
fine with me in the end but I would hate to lose Windows developers over 
this.

Erik

--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Source code control systems

[Tom P]

Hi Olaf

You are very familiar with Mercurial, could you help set up a repository
converted from FlightGear's CVS ?

I think our only hope of moving forward with this issue is to compare git
and mercurial in real-world scenarios. The git repositories at gitorious.organd
mapserver.flightgear.org have been working for a while, we need the
equivalent mercurial one for an evaluation.

P.S. I'm going through the conversion myself, but being a mercurial newbie,
cannot guarantee the result. Will let you know if it's a usable one.

  Tom


On Thu, Sep 24, 2009 at 1:56 PM, Olaf Flebbe  wrote:

> Hi Martim,
>
> > People to whom I've talked happily recommended this one:
> >
> >   http://code.google.com/p/msysgit/
> >
> >   and I'd be happy to learn about your dislike.
>
> 1) From the Installation Manual:
> http://code.google.com/p/msysgit/wiki/InstallMSysGit
>
> ...
> Note: Git for Windows is not as stable as Git for anything else. There
> are more issues with the Windows API than there are developers working
> on them.
> ...
>
> 2) From the homepage:
> "So you do not want to help? Then there is nothing to see here, please
> move along." this is not friendly for the casual user of some kind of
> middleware when I have other options.
>
> Greetings,
> Olaf
>
>
>
> --
> Come build with us! The BlackBerry® Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9-12, 2009. Register now!
> http://p.sf.net/sfu/devconf
> ___
> Flightgear-devel mailing list
> Flightgear-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
>
--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Source code control systems

[Martin Spott]

Hi Olaf,

Olaf Flebbe wrote:

> [...] this is not friendly for the casual user of some kind of 
> middleware when I have other options.

Well, they're providing installer packages and people are using it in
real-world development for a while already. Therefore I was under the
assumption that it's probably not that bad.

Did you actually have the chance to try it out ?

Cheerio,
Martin.
-- 
 Unix _IS_ user friendly - it's just selective about who its friends are !
--

--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Source code control systems

[Olaf Flebbe]

Hi Martim,

> People to whom I've talked happily recommended this one:
> 
>   http://code.google.com/p/msysgit/
> 
>   and I'd be happy to learn about your dislike.

1) From the Installation Manual:
http://code.google.com/p/msysgit/wiki/InstallMSysGit

...
Note: Git for Windows is not as stable as Git for anything else. There 
are more issues with the Windows API than there are developers working 
on them.
...

2) From the homepage:
"So you do not want to help? Then there is nothing to see here, please 
move along." this is not friendly for the casual user of some kind of 
middleware when I have other options.

Greetings,
Olaf


--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Source code control systems

[Martin Spott]

Hi Olaf,

Olaf Flebbe wrote:

> [...] I had no chance to look deeper into details. The stable git 
> command on Windows needs cygwin, which is not a minimal invasive 
> installation. (I wouldn't recommend the msys/mingw installation at this 
> point.)

People to whom I've talked happily recommended this one:

  http://code.google.com/p/msysgit/

  and I'd be happy to learn about your dislike.

Best regards,
Martin.
-- 
 Unix _IS_ user friendly - it's just selective about who its friends are !
--

--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Source code control systems

[Olaf Flebbe]

Hi,

Sorry for my late contribution to this topic: I am late catching up with 
my mails since my last holidays.

Let me tell you from my personal experiences some weeks ago with git and 
hg an linux and Windows.

Windows Implementations:

git can be tedious to use on Windows: I had big problems working on a 
project mixing up git repositories on linux pushed and pulled by a 
windows git via samba. git at some point complained about non existing 
differences: Somehow line ending issues emerged, or the object store got 
corrupted. I had no chance to look deeper into details. The stable git 
command on Windows needs cygwin, which is not a minimal invasive 
installation. (I wouldn't recommend the msys/mingw installation at this 
point.)

The hg (mercurial) Implementation of Windows is very lean, because no 
POSIX emulation layer is needed. I (luckily?) had no problems with 
respect to line endings with hg.

Branch Handling:

IMHO the git remote repository handling is complex and error prone. We 
would need a fine manual to instruct developers how to lay out their 
branches, because their are trillions of chances to mess up a repository.

(Something like 
http://wiki.samba.org/index.php/Using_Git_for_Samba_Development
)

Hg is quite easy (some say limited) with respect to this aspects. You 
can simply push your changes where you have got them, no need to mess 
with bare repositories.

In a nutshell, IMHO hg is easier to use for a random user wanting a 
quick look at the source code. Git gives the power user the opportunity 
  to implement even the unthinkable while being is a little bit beasty 
if you do not have a clean checkout.

Greetings,
   Olaf

--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Source code control systems

[Alex Perry]

On Sun, Sep 13, 2009 at 12:56 PM, Stuart Buchanan
 wrote:
> Tim Moore wrote:
>> On 09/02/2009 09:19 PM, Curtis Olson wrote:
>> >
>> > Is this an argument to stay with CVS for the data portion of the project?
>> >
>> > This is a good point to bring up though in advance.  The default project
>> > quota at code.google.com (is there a shorter
>> > abbreviation?)

CodeSite?  CS?

>> > is 1Gb so we'd be fine for SimGear and FlightGear code,
>> > but we'd blow way over that for data.

I'm happy to ask for a waiver on the size limit for CodeSite SVN or
CodeSite Hg, but I wasn't going to bring the subject up with the
administrators until our developer community has decided that this is
the preferred choice.  If it does.

>> I think this is an argument for splitting up the aircraft into multiple
>> repositories. The vast majority of space in data is used by the aircraft.
>> With a small change to flightgear to support a path list for searching
>> for aircraft, the unified data repository could be split into seperate repos
>> for each aircraft author, or it could be arranged by theme (jets, warbirds,
>> etc.)
>> if people preferred that.
>>
>> I know that people do like the ease of finding a large source of downloadable
>> aircraft in one place, in contrast to the MSFS world; the project could 
>> maintain
>> a directory of links to available (and GPL compatible) aircraft.

I like having the aircraft all in one place, and being able to do a
"$VCS sync" and go for coffee to get them all up to date.  If we use
lots of different repositories, we'll end up with a script that knows
where all the repositories are and how to check them out into a
unified directory tree.  I suspect that'll be a lot less convenient to
maintain in a platform independent manner, especially if we want to
allow for subsystem developers who don't want to use cygwin style VCS
clients.

> I'm very strongly in favour of splitting the Aircraft off from the "core" 
> data, whatever
> repository we end up using. The number and size of aircraft continues to 
> grow, far
> faster than the size of the core data.

I'd prefer to have a dependency graph (makefiles is fine) that
describes to what extent the aircraft directories aren't independent
of each other.  That would let fgrun do a real time sync of just the
aircraft I'm about to fly immediately prior to launching the
simulator.  It also makes it easier and safe for the aircraft
developers to share components.  Any aircraft developer who doesn't
want to share between aircraft doesn't need to learn how the makefiles
work.

At the extreme limit of this approach, internet connected simulators
wouldn't need to download the base image at all.  Just download the
binaries, launch fgrun, wait while it checks out the top level
makefile, then checks out all the dependencies required for fgrun
itself to work.  After that quick one-time setup, you can start making
selections on aircraft and starting location.  If you don't have the
prerequisite data, fgrun downloads it for you.  If you do, it asks
whether you would like to refresh your local snapshot from the VCS
before takeoff.  Once that is done, we know the data tree is ready for
FGFS.

The manual command line version of that preflight (i.e. without either
fgrun or terrasync) might be as simple as:
make Aircraft/c172p Airports/KMYF

Such a dynamic demand driven approach is still possible using multiple
repositories, but the scripting automation to support it will get ugly
pretty quickly.

--
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

Re: [Flightgear-devel] Source code control systems

[Stuart Buchanan]

Tim Moore wrote:
> On 09/02/2009 09:19 PM, Curtis Olson wrote:
> > 
> > Is this an argument to stay with CVS for the data portion of the project?
> > 
> > This is a good point to bring up though in advance.  The default project
> > quota at code.google.com (is there a shorter
> > abbreviation?) is 1Gb so we'd be fine for SimGear and FlightGear code,
> > but we'd blow way over that for data.
> I think this is an argument for splitting up the aircraft into multiple
> repositories. The vast majority of space in data is used by the aircraft.
> With a small change to flightgear to support a path list for searching
> for aircraft, the unified data repository could be split into seperate repos
> for each aircraft author, or it could be arranged by theme (jets, warbirds, 
> etc.)
> if people preferred that.
> 
> I know that people do like the ease of finding a large source of downloadable
> aircraft in one place, in contrast to the MSFS world; the project could 
> maintain
> a directory of links to available (and GPL compatible) aircraft.
> 

I'm very strongly in favour of splitting the Aircraft off from the "core" data, 
whatever
repository we end up using. The number and size of aircraft continues to grow, 
far
faster than the size of the core data. 

As well as reducing the size of a full checkout of the core data, it would help 
differentiate between system level data vs. aircraft, and would easily allow 
different 
policies to be used on different repos.

It would also make it a bit easier to keep everything up-to-date. My last "cvs 
up" of
data after a two week holiday took 10 minutes... almost all of which were 
aircraft changes
and therefore not critical for getting my FG fix. ;)

I don't have a strong opinion on what VCS we use. I use SVN at work, and 
haven't used
git. However, given that a large number of the active developers all use git, 
it would seem
a somewhat strange notion to go in a completely different direction, even if it 
allows us
to use code.google.com.

I'm not sure that the argument that git is harder to understand than CVS/SVN 
for new
contributers will hold much water. FG contributors are all bright people, and 
I'm sure will
manage. Of course, when I start having difficulties myself, don't forget to 
force me to eat
my own words! :)

-Stuart



  


--
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

Re: [Flightgear-devel] Source code control systems

[Tim Moore]

On 09/03/2009 06:07 PM, Curtis Olson wrote:
> On Thu, Sep 3, 2009 at 4:10 AM, Tim Moore  > wrote:

> 
> 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.
...

> 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.
> 
My point about trying hg boils down to this: if you absolutely must use
code.google.com because the infrastructure support is so compelling,
then hg is the way to go. I'd deal with using hg, perhaps via git.
But you should remember that the fg developer expertise lies very much
with git. If you're willing to consider other hosting sites than google,
savannah.org and github.com are worth checking out; we might be able
to get opendesktop.org to host us as well.

> 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".
Sounds a lot like CVSup.
> 
> 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 ...
I don't know the tool, but I think you want --keywords=off.

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

Re: [Flightgear-devel] Source code control systems

[Martin Spott]

Curtis Olson wrote:

> [...] I really appreciate those that have responded
> professionally.  This really helps to advance this discussion in a positive
> direction.

Now, if everyone involved also acts "professionally", I'm sure we're
going to see a satisfying solution pretty soon.

Cheers,
Martin.
-- 
 Unix _IS_ user friendly - it's just selective about who its friends are !
--

--
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

Re: [Flightgear-devel] Source code control systems

[Durk Talsma]

Hi Curt et al.,

Well, I guess that most has been said already, but let me weight in with just 
a few additional points. I also believe that it is time to move the 
repositories over to a higher capacity  and professionally maintained infra 
structure. My experiences with google code are generally very positive, so I 
have no objection there. My impression is that the majority of developers 
prefer git over SVN, so I believe that that should be the control system of 
choice.

Currently, the base package is growing rapidly, and I believe that for the 
next release, we should make an effort to bring it back to a size as small as 
possible. Moving the base package repository over to a new server might be the 
most excellent opportunity to split it into several smaller (optional 
packages). FWIW, I would prefer to provide only 1 aircraft (the cessna), and 
no AI stuff with the base package. That would bring the download size down 
considerably. Aircraft could be provided as separate downloads, not only from 
the website, but preferably also as a separate SVN/GIT checkout. The same 
would be true for AI. Whatever else should we be able to split off and provide 
separately.?

Finally, regardless of where we migrate to, This is also an excellent 
opportunity to think about how we provide the infrastructure for new releases 
and were we put the final download packages. Ideally, releases should be build 
on the server. During the last versions, that wasn't possible, because I 
didn't have shell access to the host, resulting in building it at home, and 
uploading it through a very slow wireless connection, with many problems as a 
result. 

if google code were to allow me to do all  those things remotely they'd get my 
vote.

Cheers
Durk




On Wednesday 02 September 2009 17:55:07 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 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 gatew

Re: [Flightgear-devel] Source code control systems

[Tom P]

Hi Anders

Finally I found the time for a benchmark, and it turns out that a complete
clone of 'data', using a 1.5Mb/s link, takes more than 3 hours.

I think that if we switch to git, and if we expect the size of 'data' to
keep growing at a brisk pace (addition of great new aircrafts, fancy new
models, ...), maybe we should plan to factor out parts of it into separate
repos.

If we move Aircraft into a separate repository (hosted on
hangar.flightgear.org :-) then we could push it to a widely-available SVN
hosting service (code.google.com) and stream to users on demand.
Think about it as the model for scenery & terrasync, but for airplanes.

I'll post another message with this idea, so that we don't clutter this
discussion, but I wanted to mention it here because it's related to how we
structure the repositories.

  Tom


$ time git clone git://mapserver.flightgear.org/flightgear flightgear
Initialized empty Git repository in /home/fg/flightgear/.git/
remote: Counting objects: 36319, done.
remote: Compressing objects: 100% (9803/9803), done.
remote: Total 36319 (delta 29320), reused 32601 (delta 26411)
Receiving objects: 100% (36319/36319), 7.81 MiB | 155 KiB/s, done.
Resolving deltas: 100% (29320/29320), done.

real1m14.823s
user0m4.872s
sys0m0.640s


$ time git clone git://mapserver.flightgear.org/simgear simgear
Initialized empty Git repository in /home/fg/simgear/.git/
remote: Counting objects: 11478, done.
remote: Compressing objects: 100% (3713/3713), done.
remote: Total 11478 (delta 8938), reused 9849 (delta 7695)
Receiving objects: 100% (11478/11478), 4.19 MiB | 155 KiB/s, done.
Resolving deltas: 100% (8938/8938), done.

real0m41.144s
user0m1.488s
sys0m0.324s


$ time git clone git://mapserver.flightgear.org/fgdata data

Initialized empty Git repository in /home/fg/data/.git/
remote: Total 112564 (delta 67668), reused 94736 (delta 56311)
Receiving objects: 100% (112564/112564), 1.63 GiB | 155 KiB/s, done.
Resolving deltas: 100% (67668/67668), done.
Checking out files: 100% (30324/30324), done.

real195m8.212s
user4m56.167s
sys1m24.461s


On Fri, Sep 4, 2009 at 7:18 AM, Anders Gidenstam
wrote:

> On Thu, 3 Sep 2009, Tom P wrote:
>
> > Hi Anders
> >
> > How long does it take you to do a shallow clone from mapserver ?
> >
> > While I've checked-out data via CVS various times in the past (and it
> takes
> > a couple of hours), I haven't been able to clone the 1.6GB fgdata
> > repository, I interrupted after a few hours.
>
> Hi,
>
> As far as I could see (and git does present how much it has downloaded
> and the achived transfer rate) git downloaded 1 GB data (i.e. the
> compressed pack).
> How much time that takes will depend on your connection, in my case it was
> limited by my 6Mbit/sec downlink so the capacity of the mapserver was not
> a bottleneck for me.
>
> I used
> git clone --depth 1 git://mapserver.flightgear.org/fgdata
>
> You can probably use --depth 0 too.
>
> Cheers,
>
> Anders
> --
> ---
> Anders Gidenstam
> WWW: http://www.gidenstam.org/FlightGear/
>
>
> --
> 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

Re: [Flightgear-devel] Source code control systems

[AC001]

Think this page on creating a "super" project and having "submodules" is 
a good read.

http://git.or.cz/gitwiki/GitSubmoduleTutorial

;-)

Mathias Fröhlich wrote:
> Hi,
>
> I also believe that we should move away from CVS.
>
> svn would have the benefit that it is very easy to use if you know cvs.
>
> Distributes systems have their huge benefits. If that DVCS is git or hg is 
> more 
> or less a matter of taste IMO.
>
> The downside is that distributes systems are more complex to handle.
> I do not know how much people out there who do occasional development - 
> especially for the aircraft models - are familiar with DVCS or want to 
> understand what happens in a DVCS.
>
> The backup problem is more or less trivially solved with DVCS since you have 
> a 
> distributed backup across the developers.
>
> Git offers to clone from a svn server (git-svn). I know several people who 
> use 
> git-svn for their personal work on a bigger project.
> So that might deliver a good compromise between a master svn and the git 
> usage 
> pattern for personal development.
> What gets lost with this approach is that 'Curt, please pull from git:...' 
> workflow we see on virtually every git hosted project.
>
> I am not sure if this fine grained access control we have today on the cvs 
> server is still needed. I would argue that this had made more problems than 
> goods in the past. But if we still need that, I am not sure if we can do that 
> with git or hg. I know that this could be done with svn but even there it is 
> more complicated than just adding group write rights on some subdirectories 
> like it is with cvs.
>
> I know that there is a git port for windows. But does this already work well 
> enough? I have never tested ...
>
> My vote would go to a DVCS.
> But I can well live with svn.
>
> Greetings
>
> Mathias
>
> --
> 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

Re: [Flightgear-devel] Source code control systems

[Mathias Fröhlich]

Hi,

I also believe that we should move away from CVS.

svn would have the benefit that it is very easy to use if you know cvs.

Distributes systems have their huge benefits. If that DVCS is git or hg is more 
or less a matter of taste IMO.

The downside is that distributes systems are more complex to handle.
I do not know how much people out there who do occasional development - 
especially for the aircraft models - are familiar with DVCS or want to 
understand what happens in a DVCS.

The backup problem is more or less trivially solved with DVCS since you have a 
distributed backup across the developers.

Git offers to clone from a svn server (git-svn). I know several people who use 
git-svn for their personal work on a bigger project.
So that might deliver a good compromise between a master svn and the git usage 
pattern for personal development.
What gets lost with this approach is that 'Curt, please pull from git:...' 
workflow we see on virtually every git hosted project.

I am not sure if this fine grained access control we have today on the cvs 
server is still needed. I would argue that this had made more problems than 
goods in the past. But if we still need that, I am not sure if we can do that 
with git or hg. I know that this could be done with svn but even there it is 
more complicated than just adding group write rights on some subdirectories 
like it is with cvs.

I know that there is a git port for windows. But does this already work well 
enough? I have never tested ...

My vote would go to a DVCS.
But I can well live with svn.

Greetings

Mathias

--
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

Re: [Flightgear-devel] Source code control systems

[Anders Gidenstam]

On Thu, 3 Sep 2009, Tom P wrote:

> Hi Anders
>
> How long does it take you to do a shallow clone from mapserver ?
>
> While I've checked-out data via CVS various times in the past (and it takes
> a couple of hours), I haven't been able to clone the 1.6GB fgdata
> repository, I interrupted after a few hours.

Hi,

As far as I could see (and git does present how much it has downloaded 
and the achived transfer rate) git downloaded 1 GB data (i.e. the 
compressed pack).
How much time that takes will depend on your connection, in my case it was 
limited by my 6Mbit/sec downlink so the capacity of the mapserver was not 
a bottleneck for me.

I used
git clone --depth 1 git://mapserver.flightgear.org/fgdata

You can probably use --depth 0 too.

Cheers,

Anders
-- 
---
Anders Gidenstam
WWW: http://www.gidenstam.org/FlightGear/

--
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

Re: [Flightgear-devel] Source code control systems

[Tom P]

Hi Anders

How long does it take you to do a shallow clone from mapserver ?

While I've checked-out data via CVS various times in the past (and it takes
a couple of hours), I haven't been able to clone the 1.6GB fgdata
repository, I interrupted after a few hours.

I'm on an 1.5 Mbps ADSL link, and I've tried both from Linux and Windows
(git-gui).
And for comparison, a clone of flightgear and simgear repos from the same
mapserver takes about 1 minute.

  Tom


On Thu, Sep 3, 2009 at 3:09 PM, Anders Gidenstam
wrote:

> On Thu, 3 Sep 2009, Anders Gidenstam wrote:
>
> > A user who isn't interested in the history can also make a shallow clone
> > with git which I would expect to be only very slightly larger than the
> > working copy itself, enabling the user to save disk space by
> > sacrificing functionality he/she isn't interested in. AFAIK there is no
> > such choice if using SVN.
>
> An update on the shallow clone:
> git keeps a compressed pack of the data in addition to the working copy.
> When cloning the current fgdata git repository from the map server with
> depth 1 this overhead adds up to about 1 GB. More overhead than I hoped
> for but still less than what one would get with SVN.
>
> It is possible to create and work on local branches even in a shallow
> clone.
>
> Cheers,
>
> Anders
> --
> ---
> Anders Gidenstam
> WWW: http://www.gidenstam.org/FlightGear/
>
>
> --
> 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

Re: [Flightgear-devel] Source code control systems

[Matias D'Ambrosio]

On Thu, Sep 3, 2009 at 7:09 PM, Anders Gidenstam
wrote:

>
>
> An update on the shallow clone:
> git keeps a compressed pack of the data in addition to the working copy.
> When cloning the current fgdata git repository from the map server with
> depth 1 this overhead adds up to about 1 GB. More overhead than I hoped
> for but still less than what one would get with SVN.
>
> It is possible to create and work on local branches even in a shallow
> clone.
>
 Another issue to consider is that of migration tools, I'm guessing CVS->SVN
is rather painless, anyone has any idea regarding git and hg?

 Here is a nice git vs SVN comparison:
 http://git.or.cz/gitwiki/GitSvnComparsion
--
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

Re: [Flightgear-devel] Source code control systems

[Anders Gidenstam]

On Thu, 3 Sep 2009, Anders Gidenstam wrote:

> A user who isn't interested in the history can also make a shallow clone
> with git which I would expect to be only very slightly larger than the
> working copy itself, enabling the user to save disk space by
> sacrificing functionality he/she isn't interested in. AFAIK there is no
> such choice if using SVN.

An update on the shallow clone:
git keeps a compressed pack of the data in addition to the working copy. 
When cloning the current fgdata git repository from the map server with 
depth 1 this overhead adds up to about 1 GB. More overhead than I hoped 
for but still less than what one would get with SVN.

It is possible to create and work on local branches even in a shallow clone.

Cheers,

Anders
-- 
---
Anders Gidenstam
WWW: http://www.gidenstam.org/FlightGear/

--
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

Re: [Flightgear-devel] Source code control systems

[Anders Gidenstam]

On Thu, 3 Sep 2009, Tim Moore wrote:

> With git, the repo size is 1.7Gb, which each user would checks out as
> well as the 2Gb working copy. However, this gives you access to the entire
> project history, for which SVN still needs access to the central server.

A user who isn't interested in the history can also make a shallow clone 
with git which I would expect to be only very slightly larger than the 
working copy itself, enabling the user to save disk space by 
sacrificing functionality he/she isn't interested in. AFAIK there is no 
such choice if using SVN.

I strongly support a move to git (Hg is a unknown card to me and IMHO it'd 
seem wiser to build on the considerable git experience already present in 
our developer community). Being able to do version controlled work on the 
data and source locally even without commit rights to the main repository 
is very valuable in my opinion.

Cheers,

Anders
-- 
---
Anders Gidenstam
WWW: http://www.gidenstam.org/FlightGear/

--
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

Re: [Flightgear-devel] Source code control systems

[Tatsuhiro Nishioka]

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  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 
> automat

Re: [Flightgear-devel] Source code control systems

[dk]

> Am new to flightgear, but read this thread, and for a tuppence worth (ducks)
>
> have you looked at launchpad.net ?
>
> thats got scm, bus tracker, teams, etc, etc
>
> What is launchpad? https://launchpad.net/+tour/index
>
> and that uses Bazaar scm
>
> regards
> Pete
>

Fortunately, there are a lot of options for a open source project. Just naming 
a few
with GIT support:
savannah.nongnu.org
gitorious.org

Hopefully we can find options for any chosen scm.

I like to fiddle with FG, and for us (without CVS write permission) a system 
with
support for local scm would mean a huge improvement.

Regards,

Diogo


--
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

Re: [Flightgear-devel] Source code control systems

[AC001]

Am new to flightgear, but read this thread, and for a tuppence worth (ducks)

have you looked at launchpad.net ?

thats got scm, bus tracker, teams, etc, etc

What is launchpad? https://launchpad.net/+tour/index

and that uses Bazaar scm

regards
Pete

Curtis Olson wrote:
> On Thu, Sep 3, 2009 at 4:10 AM, Tim Moore  > 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/ 
> 
> --

Re: [Flightgear-devel] Source code control systems

[Curtis Olson]

On Thu, Sep 3, 2009 at 4:10 AM, Tim Moore  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

Re: [Flightgear-devel] Source code control systems

[James Turner]

On 3 Sep 2009, at 10:10, Tim Moore wrote:



> Tim

Rather than add to the debate, I'll just say that I agree 100% with  
everything Tim just said, about SVN, CVS, Hg, ease of branching /  
merging and so on.

(and especially about SourceForge being a non-starter!)

James


--
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

Re: [Flightgear-devel] Source code control systems

[Tim Moore]

On 09/02/2009 09:19 PM, Curtis Olson wrote:
> On Wed, Sep 2, 2009 at 2:02 PM, Tom P  > wrote:
> 
> 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.
> 
> 
> A quick check of the 'data' repository reports it's size is about 5Gb. 
> Presumably with a distributed source code control system, each end user
> would be downloading this much data + the disk space foot print would be
> at least this much (+ maybe the extra 2Gb for a working copy?)
With git, the repo size is 1.7Gb, which each user would checks out as
well as the 2Gb working copy. However, this gives you access to the entire
project history, for which SVN still needs access to the central server.
> 
> Is this an argument to stay with CVS for the data portion of the project?
> 
> This is a good point to bring up though in advance.  The default project
> quota at code.google.com  (is there a shorter
> abbreviation?) is 1Gb so we'd be fine for SimGear and FlightGear code,
> but we'd blow way over that for data.
I think this is an argument for splitting up the aircraft into multiple
repositories. The vast majority of space in data is used by the aircraft.
With a small change to flightgear to support a path list for searching
for aircraft, the unified data repository could be split into seperate repos
for each aircraft author, or it could be arranged by theme (jets, warbirds, 
etc.)
if people preferred that.

I know that people do like the ease of finding a large source of downloadable
aircraft in one place, in contrast to the MSFS world; the project could maintain
a directory of links to available (and GPL compatible) aircraft.

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

Re: [Flightgear-devel] Source code control systems

[Tim Moore]

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  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  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  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 

Re: [Flightgear-devel] Source code control systems

[Stefan Seifert]

On Wednesday 02 September 2009 17:55:07 Curtis Olson wrote:

> 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?

Using a decentralized VCS this is no longer a problem, since there is no 
master repository anymore. So if yours goes down, people can still continue to 
work. All that would be broken is the checkout links on the website.

If we do not dare to move to git directly, I'd be all for going to SVN. It 
would be an improvement at least.

But considering that many FG developers already use it, the much increased 
fail safety, local committing, easier patch sharing and improvements for model 
developer groups like AJ mentioned and quite a few more advantages, I think we 
should really make an effort to go all the way.

Cheers,
Stefan


signature.asc
Description: This is a digitally signed message part.
--
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

Re: [Flightgear-devel] Source code control systems

[Erik Hofman]

AJ MacLeod wrote:

> With the data tree, we frequently have several people working on the same 
> area 
> (aircraft models, in particular) - not only that, but many of the people 
> working on aircraft models have historically not had any kind of commit 
> access to the main repository.  The line between user and developer is very 
> blurred in the data tree... which is why something like git seems to me to be 
> perfectly suited to the job.  
> 
> As I see it, switching to a distributed model such as Git would allow people 
> like me who have no commit access to the main repo to maintain their own work 
> under a nice version control system, greatly improve the ease of 
> collaboration with other people working on the same models, and reduce the 
> need for each individual modeller to have full commit rights (by making 
> merging so much easier for those who do have them).

I've been skeptical about moving to git but getting the base package is 
a nightmare these days and I don't see SVN improving things greatly. For 
me that's a reason to go for git at least for the base package.

Erik

--
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

Re: [Flightgear-devel] Source code control systems

[Alex Perry]

On Wed, Sep 2, 2009 at 12:02 PM, Tom P wrote:
> 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.

If we had a reliable dependency graph across the data files, it would
be easy for developers to check out only those bits of the data tree
which the test pilot actually intends to use.  I imagine it would be
possible for non-developer users who launch through fgrun to perform
incremental downloads for the requested scenario, but it seems
unlikely to me that there would be much of a benefit there.

This comment isn't intended to sway the argument either way; I think
all three options under consideration can do selective checkouts
(given the graph).

--
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

Re: [Flightgear-devel] Source code control systems

[Martin Spott]

Hi Tom,

Tom P wrote:

> But let's say that the project switched completely to GIT, would there 
> be a way to support streaming scenery ('terrasync') to the user without 
> him/her needing to clone the entire fgdata repository ?

Terrascenery is a totally independent affair and therefore not affected
by Curt's current considerations. I don't foresee us moving this off
SVN - especially given the fact that automated Scenery distribution
would hardly benefit from the extended capabilities of a distributed
SCM.

> Something like git-svnserve?!?

As far as I can tell there's no such thing as an SVN server frontend to
GIT (at least not up to the current 'official' version.

Cheers - I'm glad you like the Terrascenery service,

Martin.
-- 
 Unix _IS_ user friendly - it's just selective about who its friends are !
--

--
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

Re: [Flightgear-devel] Source code control systems

[Tom P]

Hi AJ, hi Martin

I see the advantages of GIT, no need to be convinced of that.
And I've had a look at the GIT projects on mapserver, very nice, and 
it's already split into source and data!!!


But let's say that the project switched completely to GIT, would there 
be a way to support streaming scenery ('terrasync') to the user without 
him/her needing to clone the entire fgdata repository ?

Something like git-svnserve?!?

 Tom


AJ MacLeod wrote:

On Wednesday 02 September 2009 22:44:56 Tom P wrote:
  

Yes, I agree, a distributed system is overkill for the data portion.



I would disagree...

  

1) data is handled well by a lightweight client-server model (either CVS
or SVN) that:
  - allows users and developers to synchronize their local data set,
simply and quickly



With the data tree, we frequently have several people working on the same area 
(aircraft models, in particular) - not only that, but many of the people 
working on aircraft models have historically not had any kind of commit 
access to the main repository.  The line between user and developer is very 
blurred in the data tree... which is why something like git seems to me to be 
perfectly suited to the job.  

As I see it, switching to a distributed model such as Git would allow people 
like me who have no commit access to the main repo to maintain their own work 
under a nice version control system, greatly improve the ease of 
collaboration with other people working on the same models, and reduce the 
need for each individual modeller to have full commit rights (by making 
merging so much easier for those who do have them).


I switched to using the mapserver git repo for the data tree quite some time 
ago, and the improvements for a modeller like me were massive.  No more lost 
work (I often had CVS completely botch my local changes), and all my own 
local changes nicely version controlled with an easy to follow history.


  

  - doesn't need advanced support for branching and merging

I would strongly disagree with that, from several years' experience 
collaborating on models for FG...


In case it wasn't clear by now... I think we should be using git for both 
source and data - as previously mentioned, many (if not most) FG developers 
are already using it (though missing many benefits that would arise from the 
main repo being git).


Cheers,

AJ

--
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

Re: [Flightgear-devel] Source code control systems

[Csaba Halász]

On Thu, Sep 3, 2009 at 12:17 AM, AJ
MacLeod wrote:
>
> In case it wasn't clear by now... I think we should be using git for both
> source and data - as previously mentioned, many (if not most) FG developers
> are already using it (though missing many benefits that would arise from the
> main repo being git).

I agree completely. Moving to an "intermediate" svn would hinder that
progress again.

-- 
Csaba/Jester

--
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

Re: [Flightgear-devel] Source code control systems

[Heiko Schulz]

Hi,
>In case it wasn't clear by now... I think we should be using git for both 
>source and data - as previously mentioned, many (if not most) FG developers 
>are already using it (though missing many benefits that would arise from the 
>main repo being git).

>Cheers,


>AJ
I can only agree to AJ- CVS is often a pain, I use GIT for my aircraft develope 
and I'm happy with it.
I was forced to use CVS again after my HD crash- what a pain to use...
Regards
HHS
--
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

Re: [Flightgear-devel] Source code control systems

[Martin Spott]

Tom P wrote:

> Well, it's more an argument in favor of splitting the data and source 
> code, like it's already the case for the Scenery 
> http://code.google.com/p/terrascenery/

Terrascenery is a somewhat special case in that it has almost just one
single, automated feed, it is destined to never require any review
before commit, will likely never see a branch and therefore doesn't fit
well as a comparison in the context of the current discussion.

Just for the record: Pulling Scenery from an SVN repository requires a
little bit more than twice the local disk space compared to the net
size of the respective content - which is almost the same ratio as with
GIT, at least for stuff like the Base Package.

> And here's a page comparing SVN, GIT and Mercurial. It's light on 
> details but might help a bit with the decision:
> http://www.russellbeattie.com/blog/distributed-revision-control-systems-git-vs-mercurial-vs-svn

Well, this article was written more than two years before now, when GIT
as well as Mercurial had been quite young projects. Much has changed
until now.

Cheers,
Martin.
-- 
 Unix _IS_ user friendly - it's just selective about who its friends are !
--

--
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

Re: [Flightgear-devel] Source code control systems

[AJ MacLeod]

On Wednesday 02 September 2009 22:44:56 Tom P wrote:
> Yes, I agree, a distributed system is overkill for the data portion.

I would disagree...

> 1) data is handled well by a lightweight client-server model (either CVS
> or SVN) that:
>   - allows users and developers to synchronize their local data set,
> simply and quickly

With the data tree, we frequently have several people working on the same area 
(aircraft models, in particular) - not only that, but many of the people 
working on aircraft models have historically not had any kind of commit 
access to the main repository.  The line between user and developer is very 
blurred in the data tree... which is why something like git seems to me to be 
perfectly suited to the job.  

As I see it, switching to a distributed model such as Git would allow people 
like me who have no commit access to the main repo to maintain their own work 
under a nice version control system, greatly improve the ease of 
collaboration with other people working on the same models, and reduce the 
need for each individual modeller to have full commit rights (by making 
merging so much easier for those who do have them).

I switched to using the mapserver git repo for the data tree quite some time 
ago, and the improvements for a modeller like me were massive.  No more lost 
work (I often had CVS completely botch my local changes), and all my own 
local changes nicely version controlled with an easy to follow history.

>   - doesn't need advanced support for branching and merging
I would strongly disagree with that, from several years' experience 
collaborating on models for FG...

In case it wasn't clear by now... I think we should be using git for both 
source and data - as previously mentioned, many (if not most) FG developers 
are already using it (though missing many benefits that would arise from the 
main repo being git).

Cheers,

AJ

--
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

Re: [Flightgear-devel] Source code control systems

[Tom P]

Curtis Olson wrote:
On Wed, Sep 2, 2009 at 2:02 PM, Tom P > wrote:


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.


A quick check of the 'data' repository reports it's size is about 
5Gb.  Presumably with a distributed source code control system, each 
end user would be downloading this much data + the disk space foot 
print would be at least this much (+ maybe the extra 2Gb for a working 
copy?)

Yes, I agree, a distributed system is overkill for the data portion.
But for source, it's VERY powerful and convenient, and the fact that it 
doesn't scatter CVS or .svn directories all over the tree is a major 
plus in my eye.




Is this an argument to stay with CVS for the data portion of the project?


Well, it's more an argument in favor of splitting the data and source 
code, like it's already the case for the Scenery 
http://code.google.com/p/terrascenery/


Because the two sets seem to have different requirements when it comes 
to revision control.


1) data is handled well by a lightweight client-server model (either CVS 
or SVN) that:
 - allows users and developers to synchronize their local data set, 
simply and quickly

 - for updates, the UI is very simple
 - the client is available as a library and can be embedded inside 
tools like 'terrasync'
 - the repository has a small footprint on the local system (ok, SVN is 
not ideal, but still manageable)

 - doesn't need advanced support for branching and merging
 - doesn't need local access to the entire project history

2) source can be handled equally well with a centralized server model or 
with a distributed one, but as FG development evolves, the requirements 
will grow from basic centralized revision control to:

   - advanced branching and merging
   - completely unplugged operation
(very nice, you can code on your laptop and have the entire project 
history at your fingertips)
   - support for a work-flow where many developers don't have commit 
access to the central repository and send patches




This is a good point to bring up though in advance.  The default 
project quota at code.google.com  (is there a 
shorter abbreviation?) is 1Gb so we'd be fine for SimGear and 
FlightGear code, but we'd blow way over that for data.
terrascenery is hosted on code.google.com, and that's way above 1 GB, so 
Google probably waives the limit for specific projects.




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.


Part of the goal of my original post was to have people take a look at 
SimGear in google/svn form to see if there were any major oversights 
in the migration process before we make any actual move.  But 
certainly the large size of the data is an additional dimension to test.
I'm available to test a SVN FlightGear repo on code.google.com if you 
have the time to import from CVS.
I can benchmark checkout times and disk usage and provide a comparison 
between CVS, SVN and the GIT repositories.

Just let me know, thanks.

 


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 ...)


I noticed google has an interesting system (which I haven't explored 
in detail) that allows users to rate individual commits as positive, 
neutral, or negative, with the option to leave comments.  Any changes 
to the tools also implies some changes to the typical workflow, but 
code.google.com  has some nice features. 
Yep, by switching we would get a nice issue tracker, I think it could be 
a huge improvement for the project.


It also supports mercurial (hg) which might be an option for the 
future if we decide a distributed source code management system is the 
better way to go.
And here's a page comparing SVN, GIT and Mercurial. It's light on 
details but might help a bit with the decision:

http://www.russellbeattie.com/blog/distributed-revision-control-systems-git-vs-mercurial-vs-svn



Regards,

Curt.
--
Curtis Olson: http://baron.flightgear.org/~curt/ 




--
Let Crystal Reports handle the reporting - Free Crystal R

Re: [Flightgear-devel] Source code control systems

[Matias D'Ambrosio]

On Wed, Sep 2, 2009 at 4:19 PM, Curtis Olson  wrote:

> On Wed, Sep 2, 2009 at 2:02 PM, Tom P  wrote:
>
>>  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.
>>
>
> A quick check of the 'data' repository reports it's size is about 5Gb.
> Presumably with a distributed source code control system, each end user
> would be downloading this much data + the disk space foot print would be at
> least this much (+ maybe the extra 2Gb for a working copy?)
>
> Is this an argument to stay with CVS for the data portion of the project?
>
 When using a distributed system it's not necessary to download the entire
history, it's just fine to download just the last revision and work from
there. In any case, I would bet Hg is more space efficient than CVS.


> This is a good point to bring up though in advance.  The default project
> quota at code.google.com (is there a shorter abbreviation?) is 1Gb so we'd
> be fine for SimGear and FlightGear code, but we'd blow way over that for
> data.
>
 I'm not sure how well Hg can handle binary data, it might be a good idea to
keep that elsewhere anyway for other reasons. All current SCCM allow for
separate servers for different parts.
  Matias D'Ambrosio
--
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

Re: [Flightgear-devel] Source code control systems

[Martin Spott]

Curtis Olson wrote:

> Is this an argument to stay with CVS for the data portion of the project?

I've been loosely monitoring the 'quality' of CVS checkouts for some
time now and to my experience the number of silent transmission errors
is most significant with the data repository. Therefore I don't think
that staying with CVS for the data repo is a good choice.

Cheers,
Martin.
-- 
 Unix _IS_ user friendly - it's just selective about who its friends are !
--

--
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

Re: [Flightgear-devel] Source code control systems

[Matias D'Ambrosio]

On Wed, Sep 2, 2009 at 4:02 PM, Tom P  wrote:

>  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 ...)
>
 I've used a few as well, though not Mercurial (the other available system
on Google Code). I'm partial to git, and if mercurial is similar (which I
believe it is), it's a lot more robust than SVN. It might make sense to go
directly to Mercurial (maybe going through SVN, then Mercurial, if the tools
are better for that). Even if the distriguted aspect were not an issue (I
believe it is!), SVN is lacking in some aspects.
--
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

Re: [Flightgear-devel] Source code control systems

[Curtis Olson]

On Wed, Sep 2, 2009 at 2:02 PM, Tom P  wrote:

>  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.
>

A quick check of the 'data' repository reports it's size is about 5Gb.
Presumably with a distributed source code control system, each end user
would be downloading this much data + the disk space foot print would be at
least this much (+ maybe the extra 2Gb for a working copy?)

Is this an argument to stay with CVS for the data portion of the project?

This is a good point to bring up though in advance.  The default project
quota at code.google.com (is there a shorter abbreviation?) is 1Gb so we'd
be fine for SimGear and FlightGear code, but we'd blow way over that for
data.

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.
>

Part of the goal of my original post was to have people take a look at
SimGear in google/svn form to see if there were any major oversights in the
migration process before we make any actual move.  But certainly the large
size of the data is an additional dimension to test.


> 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 ...)
>

I noticed google has an interesting system (which I haven't explored in
detail) that allows users to rate individual commits as positive, neutral,
or negative, with the option to leave comments.  Any changes to the tools
also implies some changes to the typical workflow, but code.google.com has
some nice features.  It also supports mercurial (hg) which might be an
option for the future if we decide a distributed source code management
system is the better way to go.

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

Re: [Flightgear-devel] Source code control systems

[Tom P]

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  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 wo

Re: [Flightgear-devel] Source code control systems

[Martin Spott]

Curtis Olson wrote:

> 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.

I'm very much convinced that we're able to perform proper
administration of 'our' repository via a selected group of admins. Just
look at OSGeo where only a small group of volunteers is successfully
maintaining quite a couple of critical services over years !! without
depending on so-called "professional" management.
Not the lack of ressources is holding us back from maintaining the
repository ourselves, instead this is nothing but a mental 'issue' (TM).

The most obvious drawback of your current approach with setting things
up at Google is the simple fact that you're making an unbiased decision
about FlightGear's future SCM almost impossible. Only a fool would
expect a chance to change things after they're set up and running.

> 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.

Thats quite belitteling. The fact is that a lot of developers are
already _using_ some other system right now !

> [...] 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.

Well said   especially given that SVN is much less prone to silent
transission errors compared to CVS  ;-)

Cheers,
Martin.
-- 
 Unix _IS_ user friendly - it's just selective about who its friends are !
--

--
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

[Flightgear-devel] Source code control systems

[Curtis Olson]

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/
---