Re: [Flightgear-devel] Proposal: Move airplanes to an SVN repository
I've started the first phase of trimming down fgdata. I've removed the an2 from fgdata and put it in its own repository called ac-an2 under the Flightgear project. I'm going to proceed with moving other aircraft which haven't been touched in a while into their own repos as well. When we get down to a working set of aircraft that are currently under development, I will turn off commit rights in fgdata for a short period while I extract those aircraft. I will then regenerate fgdata without the history of all the aircraft, which will shrink the fgdata repository a great deal. I've started putting ac- in front of the aircraft repository names in order to aid tools that manage aircraft downloads, etc. Aircraft developers: please don't add new aircraft to fgdata! You can easily set up your own repositories on gitorious and later request that we incorporate a repository into the Flightgear project. Tim On Thu, Aug 4, 2011 at 9:53 PM, Martin Spott martin.sp...@mgras.net wrote: Frederic Bouvier wrote: Funny (!) that the last one in the first list will be unmaintain from now if I read this ml correctly. Let's sit down and have a beer/wine/tea/vos...dka ;-) Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos much more. Register early save! http://p.sf.net/sfu/rim-blackberry-1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user administration capabilities and model configuration. Take the hassle out of deploying and managing Subversion and the tools developers use with it. http://p.sf.net/sfu/wandisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Proposal: Move airplanes to an SVN repository
I'd also add, incidentally, that creating your own repo automatically gives you commit rights to it as well. Though it would be nice to stick to some guidelines to ensure compatibility, like tagging the plane repo to match FGFS tags Alessandro Date: Fri, 12 Aug 2011 13:02:16 +0200 From: timoor...@gmail.com To: flightgear-devel@lists.sourceforge.net Subject: Re: [Flightgear-devel] Proposal: Move airplanes to an SVN repository I've started the first phase of trimming down fgdata. I've removed the an2 from fgdata and put it in its own repository called ac-an2 under the Flightgear project. I'm going to proceed with moving other aircraft which haven't been touched in a while into their own repos as well. When we get down to a working set of aircraft that are currently under development, I will turn off commit rights in fgdata for a short period while I extract those aircraft. I will then regenerate fgdata without the history of all the aircraft, which will shrink the fgdata repository a great deal. I've started putting ac- in front of the aircraft repository names in order to aid tools that manage aircraft downloads, etc. Aircraft developers: please don't add new aircraft to fgdata! You can easily set up your own repositories on gitorious and later request that we incorporate a repository into the Flightgear project. Tim On Thu, Aug 4, 2011 at 9:53 PM, Martin Spott martin.sp...@mgras.net wrote: Frederic Bouvier wrote: Funny (!) that the last one in the first list will be unmaintain from now if I read this ml correctly. Let's sit down and have a beer/wine/tea/vos...dka ;-) Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos much more. Register early save! http://p.sf.net/sfu/rim-blackberry-1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user administration capabilities and model configuration. Take the hassle out of deploying and managing Subversion and the tools developers use with it. http://p.sf.net/sfu/wandisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user administration capabilities and model configuration. Take the hassle out of deploying and managing Subversion and the tools developers use with it. http://p.sf.net/sfu/wandisco-dev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Proposal: Move airplanes to an SVN repository
On Fri, 12 Aug 2011, Tim Moore wrote: At the moment, James Turner or I would create a repo in the Flightgear project that clones yours. I think we would give you commit rights in that new repo. To make this easier, I should add a couple of people from the modeling side of the house as administrators of the Flightgear project on gitorious. However, before I start adding repositories for completely new aircraft, we should think about why new aircraft should be under the Flightgear project. Pros: centeralized location for obtaining aircraft, Flightgear seal of approval Cons: Flightgear project has to manage new repos, aircraft must be under the license that Flightgear chooses (GPL) On the Pros side the FlightGear project would also be a natural place for the aircraft to remain in case the original author stomps off in a huff or goes missing for any other reason. A personal public repository is more likely to disappear altogether. OTOH since we use git anyone with a clone at the time would have the full (public) history of the aircraft in question at hand anyway. Cheers, Anders -- --- Anders Gidenstam WWW: http://www.gidenstam.org/FlightGear/ -- Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user administration capabilities and model configuration. Take the hassle out of deploying and managing Subversion and the tools developers use with it. http://p.sf.net/sfu/wandisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Proposal: Move airplanes to an SVN repository
Sound good? Any nominations? I favor the an2, which I like, has lots of textures and sounds, and which hasn't seen any recent activity. Sounds good! Another one might be Vostok-1. It eats up 166MB and has only three commits. Torsten -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos much more. Register early save! http://p.sf.net/sfu/rim-blackberry-1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Proposal: Move airplanes to an SVN repository
I wouldn't touch the Vostock right now, it might be taken as an afront by the author Alessandro Date: Thu, 4 Aug 2011 09:50:04 +0200 From: tors...@t3r.de To: flightgear-devel@lists.sourceforge.net Subject: Re: [Flightgear-devel] Proposal: Move airplanes to an SVN repository Sound good? Any nominations? I favor the an2, which I like, has lots of textures and sounds, and which hasn't seen any recent activity. Sounds good! Another one might be Vostok-1. It eats up 166MB and has only three commits. Torsten -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos much more. Register early save! http://p.sf.net/sfu/rim-blackberry-1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos much more. Register early save! http://p.sf.net/sfu/rim-blackberry-1___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Proposal: Move airplanes to an SVN repository
Tim Moore wrote On Tue, Aug 2, 2011 at 11:39 AM, Francesco Angelo Brisa fbr...@gmail.com wrote: Any news about a possible separation of aircrafts data from the fgdata folder ? I am afraid this topic is sligtly falling into the forget about it folder :-( Cheers Francesco Some of the inertia -- on my part -- comes from the fact that the benefits are not visible until the end: until all the aircraft are removed from fgdata and fgdata is effectively regenerated through various git magic, the repository will still keep all the history, including any deleted files. However, we need to start somewhere. I had been thinking that the aircraft needed to be grouped into repos -- by theme, author, era, whatever -- but perhaps that is totally unnecessary. One thing (perhaps the only thing) that was nice about keeping aircraft in fgdata is that enforced synchronization between the aircraft and other common nasal and instrument files. However, if they are split out, maybe we will be forced to be more mature about backward compatibility, etc. So, let's choose an aircraft, preferably not one being considered for the base distribution, and suck it into its own repo. I'll perform and document the git magic, which uses git-filter-branch, to preserve history for an aircraft in the new repo. If this goes well, we'll do it with all the rest, build a new fgdata without aircraft, and drop the old one. Sound good? Any nominations? I favor the an2, which I like, has lots of textures and sounds, and which hasn't seen any recent activity. We have to start somewhere - the AN2 is as good a place as any - let's go for it. Vivian -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos much more. Register early save! http://p.sf.net/sfu/rim-blackberry-1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Proposal: Move airplanes to an SVN repository
I wouldn't touch the Vostock right now, it might be taken as an afront by the author (*Shrugs*) Looking at disk size, this list might help making decision. (from du -ms *|sort -n) 47 an2 47 F-8E-Crusader 48 A340-600 50 f16 51 Short-Stirling 58 D510 65 CRJ700-family 67 A320-family 72 MiG-15 79 767-300 101 p51d 133 IAR80 166 Vostok-1 Weigh in the number of commits: (from git log --oneline | wc -l) 2 767-300 2 CRJ700-family 3 A340-600 3 Vostok-1 4 Short-Stirling 10 D510 12 IAR80 13 A320-family 15 an2 44 MiG-15 97 F-8E-Crusader 179 p51d 269 f16 Torsten -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos much more. Register early save! http://p.sf.net/sfu/rim-blackberry-1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Proposal: Move airplanes to an SVN repository
Funny (!) that the last one in the first list will be unmaintain from now if I read this ml correctly. Regards, -Fred - Mail original - I wouldn't touch the Vostock right now, it might be taken as an afront by the author (*Shrugs*) Looking at disk size, this list might help making decision. (from du -ms *|sort -n) 47 an2 47 F-8E-Crusader 48 A340-600 50 f16 51 Short-Stirling 58 D510 65 CRJ700-family 67 A320-family 72 MiG-15 79 767-300 101 p51d 133 IAR80 166 Vostok-1 Weigh in the number of commits: (from git log --oneline | wc -l) 2 767-300 2 CRJ700-family 3 A340-600 3 Vostok-1 4 Short-Stirling 10 D510 12 IAR80 13 A320-family 15 an2 44 MiG-15 97 F-8E-Crusader 179 p51d 269 f16 Torsten -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos much more. Register early save! http://p.sf.net/sfu/rim-blackberry-1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos much more. Register early save! http://p.sf.net/sfu/rim-blackberry-1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Proposal: Move airplanes to an SVN repository
On Thursday 04 August 2011 11:36:48 Torsten Dreyer wrote: I wouldn't touch the Vostock right now, it might be taken as an afront by the author (*Shrugs*) Looking at disk size, this list might help making decision. (from du -ms *|sort -n) 47 an2 47 F-8E-Crusader 48 A340-600 50 f16 51 Short-Stirling 58 D510 65 CRJ700-family 67 A320-family 72 MiG-15 79 767-300 101 p51d 133 IAR80 166 Vostok-1 Weigh in the number of commits: (from git log --oneline | wc -l) 2 767-300 2 CRJ700-family 3 A340-600 3 Vostok-1 4 Short-Stirling 10 D510 12 IAR80 13 A320-family 15 an2 44 MiG-15 97 F-8E-Crusader 179 p51d 269 f16 Torsten The IAR80 has a separate repo, if that helps :). https://gitorious.org/iar80/iar80-repo -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos much more. Register early save! http://p.sf.net/sfu/rim-blackberry-1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Proposal: Move airplanes to an SVN repository
Frederic Bouvier wrote: Funny (!) that the last one in the first list will be unmaintain from now if I read this ml correctly. Let's sit down and have a beer/wine/tea/vos...dka ;-) Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos much more. Register early save! http://p.sf.net/sfu/rim-blackberry-1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Proposal: Move airplanes to an SVN repository
On Tue, Aug 2, 2011 at 11:39 AM, Francesco Angelo Brisa fbr...@gmail.com wrote: Any news about a possible separation of aircrafts data from the fgdata folder ? I am afraid this topic is sligtly falling into the forget about it folder :-( Cheers Francesco Some of the inertia -- on my part -- comes from the fact that the benefits are not visible until the end: until all the aircraft are removed from fgdata and fgdata is effectively regenerated through various git magic, the repository will still keep all the history, including any deleted files. However, we need to start somewhere. I had been thinking that the aircraft needed to be grouped into repos -- by theme, author, era, whatever -- but perhaps that is totally unnecessary. One thing (perhaps the only thing) that was nice about keeping aircraft in fgdata is that enforced synchronization between the aircraft and other common nasal and instrument files. However, if they are split out, maybe we will be forced to be more mature about backward compatibility, etc. So, let's choose an aircraft, preferably not one being considered for the base distribution, and suck it into its own repo. I'll perform and document the git magic, which uses git-filter-branch, to preserve history for an aircraft in the new repo. If this goes well, we'll do it with all the rest, build a new fgdata without aircraft, and drop the old one. Sound good? Any nominations? I favor the an2, which I like, has lots of textures and sounds, and which hasn't seen any recent activity. Tim -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos much more. Register early save! http://p.sf.net/sfu/rim-blackberry-1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos much more. Register early save! http://p.sf.net/sfu/rim-blackberry-1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Proposal: Move airplanes to an SVN repository
Tim Moore wrote: One thing (perhaps the only thing) that was nice about keeping aircraft in fgdata is that enforced synchronization between the aircraft and other common nasal and instrument files. However, if they are split out, maybe we will be forced to be more mature about backward compatibility, etc. Indeed, as long as ad-hoc design decisions remain being a popular strategy in FlightGear land there might be a risky adventure ahead ;-) Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos much more. Register early save! http://p.sf.net/sfu/rim-blackberry-1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Proposal: Move airplanes to an SVN repository
Any news about a possible separation of aircrafts data from the fgdata folder ? I am afraid this topic is sligtly falling into the forget about it folder :-( Cheers Francesco -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos much more. Register early save! http://p.sf.net/sfu/rim-blackberry-1___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Proposal: Move airplanes to an SVN repository
On 25 Jun 2011, at 22:59, Alex Perry wrote: . Does anybody know offhand how much trouble it would be for our source code to have all loaders of aircraft files go through a library that understands what a relative URL is? If we can cut that over, anybody can develop and host an airplane simply by sticking some static files on the web somewhere. Which can reference components of other airplanes. This is 'doable, but quite a bit of work'. What' I've been idly hacking up is a helper tool/library that would process aircraft catalogs (basically the first part of the -set.xml files, slurped together into one or several files, with the aircraft id, metatadata fields, thumbnail URL, a download URL, and an MD5 sum), and use that info to download aircraft from 'a backend' - the default backend being .zips on a HTTP server, but with the option to support an SVN repo, Git URL or whatever if the backend can be glued in. (So you'd have a stable version of the 744 pointing at an HTTP server, and a separate entry in the catalog, with a 'development' metadata flag set, pointing at the live Git repo, potentially - and could switch between them) (If the catalog entries encode the min- and max- compatible flightgear versions for a particular aircraft variant, this also gives us a way to keep the '2.0.0 compatible' archives available for legacy users, which I am sure they would appreciated) The tool code then does the work of fetching updated catalog XML files (eg, daily), and checking for updated version of aircraft, supporting multiple concurrent variants of aircraft, and crucially, placing the extracted/downloaded zip/Git repo in a place fgfs can find it. The reason I'm building this as a library/command line tool is, obviously the various GUI launchers might want to use it, but as Vivian pointed out, there are good reasons to be able to download/manage from inside FG - as was just proved with terrasync :) It *is* possible to go to the next step, and keep the .zip files as compressed blobs, like Java .jar files - but that means a lot more FG hacking to get the OSG file loaders and other places we load files, using a different stream backend. Entirely possible, but I'd sooner establish the core concept - aircraft are pulled as blobs from HTTP - before worrying about the niceties. Code wise, I have about 30% of this prototyped - but not at a point where it can be tested. Since it appears to be a hot topic, I am thinking i should revisit it for 2.5 :) James -- 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
Re: [Flightgear-devel] Proposal: Move airplanes to an SVN repository
Alex On Sat, Jun 25, 2011 at 4:01 PM, Vivian Meazza vivian.mea...@lineone.net wrote: 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. I'm not trying to defend staying on single-Git, but I think the first step is to implement on-demand loading of individual aircraft (and dependencies) and prove that it works. Otherwise we'll be exposing end users to a lot of breakage. Once we can demand load reliably, breaking the repo into many pieces is relatively trivial. 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. That's an excellent point, thank you. What I failed to mention was that some, but by no means all, models have a lighter weight version that resides in ~AI/Aircraft. Where it exists, it is this version that should be streamed for MP. Perhaps it ought to be the case for all models, but many aircraft developers never get around to it. Vivian -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Proposal: Move airplanes to an SVN repository
On 26 Jun 2011, at 07:17, James Turner wrote: Code wise, I have about 30% of this prototyped - but not at a point where it can be tested. Since it appears to be a hot topic, I am thinking i should revisit it for 2.5 :) I've tried to capture my current design/plans here: http://wiki.flightgear.org/Aircraft_deployment#Proposal_from_James It's only a proposal, and some prototype code, at this point - nothing final yet. James -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Proposal: Move airplanes to an SVN repository
On Sun, 26 Jun 2011 09:58:05 +0100, James wrote in message 91dd9863-f84a-4e33-a278-3d5f84ba7...@mac.com: On 26 Jun 2011, at 07:17, James Turner wrote: Code wise, I have about 30% of this prototyped - but not at a point where it can be tested. Since it appears to be a hot topic, I am thinking i should revisit it for 2.5 :) I've tried to capture my current design/plans here: http://wiki.flightgear.org/Aircraft_deployment#Proposal_from_James ...(Keeping in mind the aircraft-manager tool has to run on Windows) ..would cygwin help us support the Windows crowd here, e.g. by using gygwin to call etc in the resources that Microsoft Windows doesn't support and that FG needs? It's only a proposal, and some prototype code, at this point - nothing final yet. James -- ..med vennlig hilsen = with Kind Regards from Arnt Karlsen ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Proposal: Move airplanes to an SVN repository
James wrote On 26 Jun 2011, at 07:17, James Turner wrote: Code wise, I have about 30% of this prototyped - but not at a point where it can be tested. Since it appears to be a hot topic, I am thinking i should revisit it for 2.5 :) I've tried to capture my current design/plans here: http://wiki.flightgear.org/Aircraft_deployment#Proposal_from_James It's only a proposal, and some prototype code, at this point - nothing final yet. This all looks good so far as it goes, but my main concern is that it looks as if it would involve a great deal of work. James is a busy man: is it over ambitious to expected a working and tested solution by release 2.5?. Do we need some form of interim solution to the pressing need to sort out FGData now? Vivian -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Proposal: Move airplanes to an SVN repository
As a general rule I'd propose to make a clear distinction between a) datasets, b) hosting sites and c) protocols or revision control systems (at least). Some people are implying SVN when talking about hosting large datasets, others are implying Gitorious when talking about GIT. Continuing this mixup will be prohibitory to distilling a coherent result from the discussion. Have fun, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Proposal: Move airplanes to an SVN repository
On Sun, 26 Jun 2011, Martin Spott wrote: As a general rule I'd propose to make a clear distinction between a) datasets, b) hosting sites and c) protocols or revision control systems (at least). Some people are implying SVN when talking about hosting large datasets, others are implying Gitorious when talking about GIT. Continuing this mixup will be prohibitory to distilling a coherent result from the discussion. I'd be happy to host some kind of startup service that would at least get the ball rolling. Once it's ready, it could be mirrored so as not to totally hammer my net connection. :) g. -- Proud owner of F-15C 80-0007 http://www.f15sim.com - The only one of its kind. http://www.simpits.org/geneb - The Me-109F/X Project Some people collect things for a hobby. Geeks collect hobbies. ScarletDME - The red hot Data Management Environment A Multi-Value database for the masses, not the classes. http://www.scarletdme.org - Get it _today_! Political correctness is a doctrine, fostered by a delusional, illogical minority, and rabidly promoted by an unscrupulous mainstream media, which holds forth the proposition that it is entirely possible to pick up a turd by the clean end. -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Proposal: Move airplanes to an SVN repository
Hi, Currently I do not even have a working fg on my machine, but I continue to peek at the flightgear-devel list occasionally. Today I saw this discussion of moving the aircraft directories to individual SVN repos instead of git. My experience with both svn and git is both minimal and old, and I may be misinterpreting what the problem is that needs solving. However, if you're going to consider creating separate repos in SVN for each aircraft, when everything else has been converted to git now, perhaps you should consider instead using fossil, which is very git-like in some ways (clone,push,pull) but also like a traditional centralized VCS in some other ways. In particular, fossil's repository is a single, sqlite file. Although cloning is the normal method for copying it, you can copy that file just fine (as long as no one else is updating it at that instant) and it works fine. Afterwards, updating a local repo, using pull, involves an rsync-like protocol so it's fast. Fossil repositories can be converted to/from git repositories with a one-liner. (However I don't know how you would isolate, say, just the c172p directory from all the rest of the stuff in git.) If anyone thinks this might be relevant, just take a look at https://www.fossil-scm.org/index.html/doc/trunk/www/index.wiki This is a living instance of a fossil repository, BTW: the fossil binary, statically-linked except for libz, is ~900KB. Yet it includes a simple wiki, a *very* nice issue-tracking system, and a tiny web-server(!). Normally a developer interacts with fossil from the commandline, but the built-in web-server makes *exploring* what is in the repository, as well as creating bug reports and some documentation, a joy. Just for fun, and understanding that this would have to be done properly by someone with access to the full git repo with all its history, I yum-installed FlightGear-data on my Fedora system, and then did cp -r /usr/share/FlightGear/Aircraft /tmp and created Fossil repos for each of the included directories: shrdlu tmp $ ls Aircraft 777-200 bo105 dhc2 Generic j3cub ufo A6M2 c172p Dragonfly Instruments SenecaII UIUC b1900d CitationX f-14b Instruments-3d sopwithCamel ZLT-NT shrdlu tmp $ mkdir Repos shrdlu tmp $ cd Aircraft shrdlu Aircraft $ for i in * do echo $i: fossil new ../Repos/$i.fossil cd $i fossil open ../../Repos/$i.fossil fossil add . fossil commit -m Initial checkin fossil close cd .. done #Five times it paused to ask a question like this: # ./Models/Liveries/KLM.xml contains CR/NL line endings; commit anyhow (yes/no/all)?all #Otherwise it would have taken perhaps 30 seconds for all 18 repositories, #on my 5-year-old machine. shrdlu Aircraft $ cd .. shrdlu tmp $ du -sh Aircraft 12M Aircraft/777-200 4.5MAircraft/A6M2 6.0MAircraft/b1900d 3.0MAircraft/bo105 17M Aircraft/c172p 5.8MAircraft/CitationX 5.9MAircraft/dhc2 1.6MAircraft/Dragonfly 23M Aircraft/f-14b 816KAircraft/Generic 14M Aircraft/Instruments 11M Aircraft/Instruments-3d 1.1MAircraft/j3cub 6.6MAircraft/SenecaII 22M Aircraft/sopwithCamel 216KAircraft/ufo 8.2MAircraft/UIUC 4.1MAircraft/ZLT-NT shrdlu tmp $ ls -lh Repos total 68M -rw-r--r-- 1 dns dns 7.5M Jun 25 13:43 777-200.fossil -rw-r--r-- 1 dns dns 1.6M Jun 25 13:43 A6M2.fossil -rw-r--r-- 1 dns dns 3.3M Jun 25 13:43 b1900d.fossil -rw-r--r-- 1 dns dns 1.4M Jun 25 13:43 bo105.fossil -rw-r--r-- 1 dns dns 11M Jun 25 13:43 c172p.fossil -rw-r--r-- 1 dns dns 3.4M Jun 25 13:43 CitationX.fossil -rw-r--r-- 1 dns dns 3.2M Jun 25 13:43 dhc2.fossil -rw-r--r-- 1 dns dns 836K Jun 25 13:43 Dragonfly.fossil -rw-r--r-- 1 dns dns 11M Jun 25 13:44 f-14b.fossil -rw-r--r-- 1 dns dns 464K Jun 25 13:44 Generic.fossil -rw-r--r-- 1 dns dns 3.9M Jun 25 13:44 Instruments-3d.fossil -rw-r--r-- 1 dns dns 5.4M Jun 25 13:44 Instruments.fossil -rw-r--r-- 1 dns dns 457K Jun 25 13:44 j3cub.fossil -rw-r--r-- 1 dns dns 2.4M Jun 25 13:44 SenecaII.fossil -rw-r--r-- 1 dns dns 8.7M Jun 25 13:44 sopwithCamel.fossil -rw-r--r-- 1 dns dns 96K Jun 25 13:44 ufo.fossil -rw-r--r-- 1 dns dns 2.8M Jun 25 13:44 UIUC.fossil -rw-r--r-- 1 dns dns 1.4M Jun 25 13:44 ZLT-NT.fossil shrdlu tmp $ file Repos/777-200.fossil Repos/777-200.fossil: SQLite 3.x database shrdlu tmp $ du -sh Aircraft Repos 144MAircraft 68M Repos shrdlu tmp $ Of course this is equivalent to just the tip of the git repository. Fossil uses deltas for versions internally, so it ought to be competitive on the full history, but only an experiment will prove that. Perhaps this is of some interest. If not, just ignore me. david. -- 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
Re: [Flightgear-devel] Proposal: Move airplanes to an SVN repository
On Saturday 25 June 2011 12:28:14 David Slocombe wrote: Hi, Currently I do not even have a working fg on my machine, but I continue to peek at the flightgear-devel list occasionally. Today I saw this discussion of moving the aircraft directories to individual SVN repos instead of git. The major drawback of GIT over CVS and SVN in this instance is GIT treats the repository as an atomic whole. CVS and SVN have the ability to provide partial checkouts, that is you could update a single directory or even just a single file without updating the whole thing. This becomes important when the repository grows into the multigigabyte size range. Ron -- 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
Re: [Flightgear-devel] Proposal: Move airplanes to an SVN repository
On Fri, Jun 24, 2011 at 6:51 AM, Scott scott.hamil...@popplanet.biz wrote: Using SVN so you can download stuff on the fly is ridiculous, The most popular and platform agnostic way to do downloading from multiple locations, with caching and automatic updates, is HTTP these days. Does anybody know offhand how much trouble it would be for our source code to have all loaders of aircraft files go through a library that understands what a relative URL is? If we can cut that over, anybody can develop and host an airplane simply by sticking some static files on the web somewhere. Which can reference components of other airplanes. -- 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
Re: [Flightgear-devel] Proposal: Move airplanes to an SVN repository
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
Re: [Flightgear-devel] Proposal: Move airplanes to an SVN repository
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
Re: [Flightgear-devel] Proposal: Move airplanes to an SVN repository
On Sat, Jun 25, 2011 at 4:01 PM, Vivian Meazza vivian.mea...@lineone.net wrote: 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. I'm not trying to defend staying on single-Git, but I think the first step is to implement on-demand loading of individual aircraft (and dependencies) and prove that it works. Otherwise we'll be exposing end users to a lot of breakage. Once we can demand load reliably, breaking the repo into many pieces is relatively trivial. 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. That's an excellent point, thank you. -- 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
Re: [Flightgear-devel] Proposal: Move airplanes to an SVN repository
On Fri, 2011-06-24 at 10:48 +, 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. This makes it really, really difficult to obtain an initial checkout of the fgdata folder, expecially for people that do not have a very good connection. at the same time it is not possible, to my knowledge, to only grab part of the repository. And most people don't really need he entire repository anyway. GIT is fantastic to handle code with many contributors, but I think it is really overkill for airplanes, where usually the number of people contributing to a single plane is fairly small and is unlikely that two people should work on the same file at the same time. Also, using SVN for planes the same way that is being used for scenery would allow individual planes to be pulled by a frontend, much like scenery is. Or even to be pulled by FGFS itself, though that's probably science fiction at this moment in time. So, is this something that could be implemented in the future? Am I barking up the wrong tree? I can foresee some issues, like, where should the repository be hosted, any other thing I have overlooked? 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 -- 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
Re: [Flightgear-devel] Proposal: Move airplanes to an SVN repository
Erik wrote On Fri, 2011-06-24 at 10:48 +, 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. This makes it really, really difficult to obtain an initial checkout of the fgdata folder, expecially for people that do not have a very good connection. at the same time it is not possible, to my knowledge, to only grab part of the repository. And most people don't really need he entire repository anyway. GIT is fantastic to handle code with many contributors, but I think it is really overkill for airplanes, where usually the number of people contributing to a single plane is fairly small and is unlikely that two people should work on the same file at the same time. Also, using SVN for planes the same way that is being used for scenery would allow individual planes to be pulled by a frontend, much like scenery is. Or even to be pulled by FGFS itself, though that's probably science fiction at this moment in time. So, is this something that could be implemented in the future? Am I barking up the wrong tree? I can foresee some issues, like, where should the repository be hosted, any other thing I have overlooked? 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. Something must be done, this is something, therefore it should be done :-). Seriously, Git has never been right for the data. We were promised a fix, which has never materialized. SVN can be no worse, and it might be better. Terrasync indicates that it might well be better, and might give us the ability to pull aircraft down for MP on the fly. I agree with Erik. Perhaps Alessandro would take this forward with some more concrete proposals that we could consider. 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
Re: [Flightgear-devel] Proposal: Move airplanes to an SVN repository
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 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
Re: [Flightgear-devel] Proposal: Move airplanes to an SVN repository
On Fri, Jun 24, 2011 at 1:13 PM, Vivian Meazza vivian.mea...@lineone.net wrote: Seriously, Git has never been right for the data. We were promised a fix, which has never materialized. SVN can be no worse, and it might be better. Terrasync indicates that it might well be better, and might give us the ability to pull aircraft down for MP on the fly. Ok, here is my usual negative comment (only by request :P) Could we please forget SVN forever? Thank you. Applies to scenery too, although I have been told its use was introduced to get free hosting from google and not for technical merit. Using SVN so you can download stuff on the fly is ridiculous, that's not the task of a revision control system (and built scenery probably doesn't need a revision control anyway). For all development tasks SVN is clearly worse than GIT (branches, local changes, merge requests, client side history, backups, etc.), and it isn't particularly good at the download part either. Also, an eventual automated aircraft download system should allow for 3rd party hangars too (would be the most important benefit, if you ask me), and not force SVN upon everybody. We should keep it simple, and probably just use regular snapshots from the revision control system made available via http. To summarize: if we want to split fgdata or allow automatic aircraft (model) downloads, that's fine with me, but I don't think SVN is the right tool for the task(s). -- Csaba/Jester -- 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
Re: [Flightgear-devel] Proposal: Move airplanes to an SVN repository
On Fri, 2011-06-24 at 15:20 +0200, Csaba Halász wrote: On Fri, Jun 24, 2011 at 1:13 PM, Vivian Meazza vivian.mea...@lineone.net wrote: Seriously, Git has never been right for the data. We were promised a fix, which has never materialized. SVN can be no worse, and it might be better. Terrasync indicates that it might well be better, and might give us the ability to pull aircraft down for MP on the fly. Ok, here is my usual negative comment (only by request :P) Could we please forget SVN forever? Thank you. Applies to scenery too, although I have been told its use was introduced to get free hosting from google and not for technical merit. Using SVN so you can download stuff on the fly is ridiculous, that's not the task of a revision control system (and built scenery probably doesn't need a revision control anyway). For all development tasks SVN is clearly worse than GIT (branches, local changes, merge requests, client side history, backups, etc.), and it isn't particularly good at the download part either. Also, an eventual automated aircraft download system should allow for 3rd party hangars too (would be the most important benefit, if you ask me), and not force SVN upon everybody. We should keep it simple, and probably just use regular snapshots from the revision control system made available via http. To summarize: if we want to split fgdata or allow automatic aircraft (model) downloads, that's fine with me, but I don't think SVN is the right tool for the task(s). I agree (FWIW). We don't use the fgdata like a normal code revision repository. It's a bit like the analogy to guy with a hammer, ever problem can be fixed by hitting it So there probably needs to be some discussion of what we really need first; Each aircraft developer can have their own code repository somewhere (Git, SVN, whatever), It needs a way to package that aircraft so it can be deployed easily to the FG Install directory, something along the lines of a Java Enterprise Archive or a RedHat RPM file. Something that allows FG to track the installed version, and enforce minimum dependencies. Something that is transport agnostic (HTTP, FTP, SVN, SSH) Something that allows the install to be relocatable in the file tree (so you can deploy a development release and not mess up your live version, like --fg-aircraft) S. -- 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
Re: [Flightgear-devel] Proposal: Move airplanes to an SVN repository
Csaba wrote On Fri, Jun 24, 2011 at 1:13 PM, Vivian Meazza vivian.mea...@lineone.net wrote: Seriously, Git has never been right for the data. We were promised a fix, which has never materialized. SVN can be no worse, and it might be better. Terrasync indicates that it might well be better, and might give us the ability to pull aircraft down for MP on the fly. Ok, here is my usual negative comment (only by request :P) Could we please forget SVN forever? Thank you. Applies to scenery too, although I have been told its use was introduced to get free hosting from google and not for technical merit. Using SVN so you can download stuff on the fly is ridiculous, that's not the task of a revision control system (and built scenery probably doesn't need a revision control anyway). For all development tasks SVN is clearly worse than GIT (branches, local changes, merge requests, client side history, backups, etc.), and it isn't particularly good at the download part either. Also, an eventual automated aircraft download system should allow for 3rd party hangars too (would be the most important benefit, if you ask me), and not force SVN upon everybody. We should keep it simple, and probably just use regular snapshots from the revision control system made available via http. To summarize: if we want to split fgdata or allow automatic aircraft (model) downloads, that's fine with me, but I don't think SVN is the right tool for the task(s). All good stuff - but when are we likely to see this hypothetical improved system? So what is the right tool? Our Git repo is clearly not fit for purpose as it stands, and I'm really fed up with doing battle with it with inadequate weapons. 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
Re: [Flightgear-devel] Proposal: Move airplanes to an SVN repository
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
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 +, 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
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 +, 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
Re: [Flightgear-devel] Proposal: Move airplanes to an SVN repository
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 +, 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
