Alex wrote > 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. >
The main problem right now is that Git cannot cope with the size of the data, and it's getting worse by the day. The Git data repo on Gitorious is no longer fit for purpose as currently configured. Streaming was mentioned (perhaps as a nice-to-have) in the context of Multiplayer. If you didn't have a particular model then it might be streamed instead of showing the rocket propelled blue and yellow glider. Vivian ------------------------------------------------------------------------------ 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
