Putting map data on SVN made incremental updates feasible. Both for maintainer uploads, and user caches. A similar argument applies to the aircraft, with the complications that (a) there are more maintainers with less coordination, and (b) the dependency graph between directories is not trivial. On the other hand, we don't need streaming on-demand retrieval since few pilots are expected to change aircraft in mid-flight. 8-)
Those two complications mean that either we have to do a whole checkout (in which case we might as well use GIT) or maintainers have to mark up their directories with dependency metadata to support automated update tools (in which case SVN would work but not be ideal). I think the critical question is whether maintainers are willing to do that. Suppose they are. A post-commit hook collects all the dependency data, sprinkled across the directories, into a single self-consistent file. The client side utility does a single update to get that file, and then whatever additional updates it specifies for the desired aircraft. SVN would work well enough. We would know the total bandwidth cost for each aircraft (before caching). Supposing we continue to use GIT for development and whole-repository replication, and replace SVN with HTTP for people who want to do quick and incremental aircraft downloads. We can easily prototype the HTTP version by selecting a 1GB subset of the archive for demonstration using AppEngine free quota ... while the community evaluates that prototype. The replica of GIT head in appengine is about $2/month. Add about $1 for any user who chooses to use HTTP to replicate the entire repository instead of using GIT (but we can discourage that). Assuming most individual aircraft are a tiny fraction of the repository (especially after allowing for texture reuse), the true expenses are probably quite manageable. http://code.google.com/appengine/docs/billing.html There are probably cheaper static web hosting options out there, but I figured these numbers are a useful starting point. Personally, I don't see a value in offering HTTP per-file instead of SVN per-directory, but others may do. Hence the discussion above. ------------------------------------------------------------------------------ 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
