On Friday, June 24, 2011 05:19:58 AM Francesco Angelo Brisa wrote:
> 2011/6/24 TDO_Brandano - <tdo_brand...@hotmail.com>
>
> > 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. [...]
>
> I agree with Brandano, airplanes data is way too big for git, and the
> problem will only get worst with time.
> I would keep in git only a maximum of 3 aircrafts + UFO for scenery
> building.
> The rest should be kept away (I have no good idea right now). Can't the
> repository be hosted on the same server of the fgdata ?
>
> Cheers
> Francesco
1. GIT is not the real issue as it is a powerful version control tool that can
handle as much as any other tool out there.
2. The real issue is that fgdata is too big resulting in huge downloads and
developers getting all kinds of stuff that they don't need. That is most of
the work in fgdata is aircraft work and most aircraft devs only touch one or
two of the hundreds of aircraft in the repository.
3. Regardless of what source code control system is used #2 is still an issue
unless fgdata/Aircraft is somehow decomposed into seperate repositories for
each aircraft.
4. I think #3 applies to all aircraft including the UFO and any other "core"
aircraft. That is all aircraft should have code managed in the same way.
5. Having seperate aircraft repositories implies that there will be an "fgdata
build" that can create a fully functional fgdata directory with some set of
aircraft.
5a. Perhaps this "build" can be configured by the user to use the aircraft
status as a way to filter which aircraft are included in the "build" and
perhaps there should be a small default set of aircraft that are always part
of the "build".
5b. For those following GIT who need to do regualr updates to fgdata to keep
it in sync with fgfs GIT this will make that process faster and less bandwidth
hungery.
6. Because we now have a functioning --fg-aircraft configuration using seperate
repositories should be easy for aircraft devs to setup even if they are
working on more than one aircraft.
7. Having seperate repositories for each aircraft would also facilitate
managing who has commit and review privilages for each aircraft and allow for
more fine grained security.
8. There are a lot of details that need to be sorted out to make this work.
Hal
>
> > Waiting for comments, flames and people asking "who is this guy?", yours
> > sincerely,
> >
> > Alessandro Garosi (aka Brandano on IRC)
> >
> >
> > -------------------------------------------------------------------------
> > ----- 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
