On Sun, Sep 13, 2009 at 12:56 PM, Stuart Buchanan <stuart_d_bucha...@yahoo.co.uk> 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
