Alessandro,
Seems like good summary to me.
You mean that I've been working on terrasync/svn for nearly 2 weeks, and
it's unnecessary? As I recall it, at least part of the choice of SVN for the
scenery repo was that Windows didn't have a native rsync utility, and SVN
represented a fairly ready-made alternative. The choice of Google might well
have been influenced by the cost.
Why don't you just do it? You don't need full access to Gitorious data repo
to produce a proof-of-principle repo using the proposed structure. If it
works, and the bugs have been ironed, then all the data could be migrated to
it. And in any case we shouldn't abandon the old until the new is up and
running.
Vivian
-----Original Message-----
From: TDO_Brandano - [mailto:tdo_brand...@hotmail.com]
Sent: 24 June 2011 18:46
To: Flightgear Devel List
Subject: Re: [Flightgear-devel] Proposal: Move airplanes to an SVN
repository
Ok, let me sum up a few of the day's IRC discussions.
The size of the GIT repository is a real issue, and I am not the only one
that perceives it as such. At the same time, SVN suffers from several
disadvantages compared to GIT, even from the point of view of reliability.
Even the map data should not really be hosted on SVN, but it's mainly hosted
there because we get that hosting for free from Google. Everyone agrees that
the Aircraft data would be better off split aside from the rest of fgdata
now that FGFS can load them from a separate folder. Several people find the
idea of loading single planes at launch time or at runtime interesting. SVN
is not really required to do this, the planes could be hosted on a separate
server as archives and either installed, or, in the far future, loaded as
compressed archives. To do this there must be some sort of structure keeping
track of dependencies for single planes, version compatibility and available
planes so that download packages can be generated automatically and
developers can download the entire thing via a script or something similar
if they want to. The ideal situation would have a repository for each
aircraft or for each author, to allow individual authors GIT access for
their own planes. There's planes where the author is unknown or is long
missing, and those will need anyway to be kept under version control since
changes to FGFS might break compatibility in the future. Also, fragmenting
the repository might mean that some author could choose to use a different
or more recent license for her plane, so we need to keep track of this info
as well. At the very least an automatic downloader should either filter the
downloads based on license or prompt the user for approval. Someone on IRC
has volunteered to do this work, but I won't name names until I am sure he
is being serious and that he is reliable, since I think he would need some
pretty powerful rights on the repository to do this. Am I missing anything
else?
Alessandro (Brandano)
> Date: Fri, 24 Jun 2011 17:41:36 +0200
> From: flightg...@sablonier.ch
> To: flightgear-devel@lists.sourceforge.net
> Subject: Re: [Flightgear-devel] Proposal: Move airplanes to an SVN
repository
>
> Am 24.06.11 12:55, schrieb Erik Hofman:
> > On Fri, 2011-06-24 at 10:48 +0000, TDO_Brandano - wrote:
> >> Ok, before I get flamed to a crisp, let me explain what is my
> >> reasoning behind this. Right now the fgdata repository is about 9 GB.
> >
> > It has been proposed before and I believe it's the way to go. It's just
> > a matter of someone stepping up for the task.
> >
> > Erik
> >
>
> Everyone is free to build a own "hangar" on gitorious, everyone is free
> to develop, exchange, merge in, push, to discuss and bring different
> aircrafts together in his own hangar. No hierarchical centralized system
> is needed with git and gitorious/github, you merge in or push whatever
> you want. People can clone, pull, merge, push, watch, organize, whatever
> they want. No one will ask. You collaborate or not, you build your own
> hangar, it is your choice, YOU set permissions, YOU give access, YOU
> share permissions or not. You give people links here and there to
> provide "your" aircrafts or aircrafts of "canadian group of most serious
> aircrafts" or whatelse. An educational hangar, a polar ice hangar, a
> chopper hangar, a historical hangar ...
>
> I really don't know why most people here use gitorious and git like a
> hierarchical system of the romans with asking for permissions, sending
> merge requests to some development sub-kings, waiting for this and that.
> It is not necessary, just see the freedom, use git as it is probably
> thought, and open your own personal-number-one-hangar, show your work,
> and "git reset --hard" yourself when necessary ;-)
>
> And meantime fgdata core developers try to find consensus about 10 or 15
> aircrafts remaining in basic fgdata (Arghh! Consensus!). That is what
> was requested here some months ago (hey, fgdata core developers, with
> all my respect, don't fear to say which are the best aircrafts we have!,
> and please do not wait for Tim, I guess he will not do that job for you).
>
> Of course, this are my very very personal thoughts, please do not blame
> me for that, it is not necessary. I have to say we will introduce
> something new in the new FlightGear Launcher FGx the next months: You
> can choose a hangar and update your aircrafts by DIFFERENT hangars.
> Unfortunately we can't do it with git directly, but I am sure we will
> find something like a "general hangar protocol" ;-) a xml file or
> something on top of every hangar with short aircraft description or
> whatever, which can be set up and provided by EVERYONE in the world with
> some space left on a server. The rest will be done by FGx and a built-in
> installer. Only restriction: all must be free and open source. And what
> a chaos you will say, everyone uses different aircrafts. But this is
> what some users want -> no kings and no 9 GB downloads.
>
> Cheers, Yves
>
>
----------------------------------------------------------------------------
--
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense..
> http://p.sf.net/sfu/splunk-d2d-c1
> _______________________________________________
> Flightgear-devel mailing list
> Flightgear-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense..
http://p.sf.net/sfu/splunk-d2d-c1
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
