Re: [Flightgear-devel] FGData Split Completed - a.k.a. Life after the Split
On Tue, Oct 18, 2011 at 04:21:47PM -0600, dave perry wrote: On 10/18/2011 10:24 AM, Cedric Sodhi wrote: - Development - All aircraft related development shall henceforth be performed on repositories which are maintained by the respective authors. It is planned that most of the repositories on https://gitorious.org/flightgear-aircraft will be dissolved over time and be taken over by the respective authors. I don't understand the above (up to - Development -). Questions: 1. Are you saying that aircraft developers cannot leave their aircraft in https://gitorious.org/flightgear-aircraft indefinitely? So do we need to set up our own git repository for each ac we maintain? This raises the knowledge/experience bar required for aircraft developers/maintainers. As it turns out, the majority of those currently involved in the discussion on this mailing list (see the thread which Thorsten started on AC repositories) seem not to agree with that, although it is indeed the suggestion which I made. Instead, Thorsten et al welcome you to use the infrastructure of the official aircraft repository https://gitorious.org/flightgear-aircraft to officially publish your planes as part of the Flightgear project. 2. Assuming the answers are no, yes, to #1, will all these repositories be centrally located so one can track new or modified ac of interest? If you do not wish to publish your planes under the conditions outlined above, for instance because you don't want to use Gitorious or because your plane is not GPL, then, so Thorsten, you will not be entitled to be listed and tracked centrally (I personally don't agree with that). -- regards, ManDay -- 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-oct ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear aircraft repository
On Wed, Oct 19, 2011 at 10:28:33AM +0300, thorsten.i.r...@jyu.fi wrote: As for the topic brought up here, I sense a bit of sentimentalism clouding the technical judgment of some. (...) In a positive creative development structure you leave the contributors their freedom. Contribute your planes! rather than Come to Gitorious, ask for our permission to get your repository, work under our supervision! Work, work, my busy bees, and make us planes for our big master-repository! You can also offer your work as part of 'The Flightgear Project'. Once you decide to do so, it is no longer your freedom to do what you want with your work - it is under the control of 'The Flightgear Project', you may have to compromise, you can't choose your license, But you get something in return for giving up that freedom - you get to use the official Flightgear infrastructure (you aircraft will be for download on the official page, others test compatibility, other developers may take care of your work when you're not around, others will feel responsible to provide support if they can,...). This is exactly the deal which I think you are rather hurting yourself with. I allege, that contributers of planes are not looking to make a deal with you, at least I would not. What you are offering them, is what *every* contributor should be entitled to in the first place. You only get to be on our download page if you surrender your autonomy to us? What are you trying to achieve? Do you really think anyone would readily change their mind to rather publish their plane as GPL, although they'd prefer not to, and give up their autonomy, although they'd prefer not to, to get a goodie from you? Again: What are you trying to achieve? Are you trying to promote GPL by sanctioning people for not using it? Or is it only about some personal pride thing, and you don't want to feel exploited by those, who contribute (that sounds ridicolous enough as it stands)? You seem to entertain the idea of a free lunch - get the goodies which being part of the Flightgear project has to offer, but keeping the freedom to do what you want. That may be a positive creative development structure from your personal point of view, but certainly not for everyone else who is then supposed to provide infrastructure for you. If you consider those, who contribute planes, looking for a free lunch, I seriously must wonder what kind of attitude you presume in an open source project. What is that lunch exactly? The fame, perhaps? And instead of considering listing even non-GPL planes on the main-page a good thing for Flightgear, you rather wish to deprive those who contributed them of their fame? it's just common sense that there has to be a balance between give and take whenever people interact and work together. Again, I can't help it but wonder what image you have in mind when you accuse those, who voluntarily make planes for Flightgear, of taking from you but not giving back. I can't even imagine what your opinion of people who only use Flightgear, and develop neither code nor planes for it, must be... And as for other developers may take care of your work when you're not around, others will feel responsible to provide support if they can,...). I think we have sufficiently seen how other people's work is taken care of after they leave. And how much it helps in this regard, that the planes are forced under the hood of GPL and subjected to your authority, your restrictions. I think old, abandoned planes will equally, if not more likely be willingly taken over by others, if they are not forced into a master-repo. This has nothing to do with what technical possibilities GIT offers, or what GIT is about Yes, it has everything to do with what Git(orious) is about. Because Gitorious demonstrates what a sustainable, distributed development structure works like, and your suggestion is nothing like that. You completely misregard fundamental properties of distributed development, such as cloning and branching. Your desire to patronize the other developers may be more fit for core and code development, but the development of planes differs substantially from that of the core: Planes are contributed modularily, have no strong interaction amonst eachother and can thus be contributed freely, as in the freedom to contribute or not. If you like to obtain authority over a plane, cloning it into your own repository will allow you to call it your own, while you can still savour the development the author makes. And if the author seems to abandon the plane or changes things of which you disapprove, branching will allow you to continue development as if it had always been your own. So, if you like your complete freedom, you can't be part of a collaborative project. It's as simple as that, being part of a bigger project always implies giving up that complete freedom. No one gives up any freedom here, since it's their free and voluntary
Re: [Flightgear-devel] FlightGear aircraft repository
Hello again, I would like to add that I agree, that making any implication about whether authors *should* migrate their planes to their own repos, was wrong. There is of course no reason to turn them away, if only, there is a reason to request them to be part of the central Gitorious-Account (as it is the subject of this thread). regards, ManDay On Wed, Oct 19, 2011 at 10:28:33AM +0300, thorsten.i.r...@jyu.fi wrote: -- 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-oct ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FGData Split Completed
Hello everybody, I apologize if my initial mail did not describe it clearly enough. I hope this mail helps with all of your questions: Before you go on a disclaimer ahead: There has been a minor (not just in a manner of speaking) complication with the new FGDATA repository, so there is now a new-new fgdata repository (which has that minor issue rectified, although the old-new fgdata was perfectly usuable aswell). We are currently doing the final reviews on the new-new fgdata and that should be the fgdata to pull, once everything is verified. There are the following repositories now: fgdata an2 14bis 21 707 717 727-230 737-100 737-200 737-300 737ng600 737ng700 737ng800 737ng900 747 ...etc... = The first repository is the plain fgdata which everyone will need to clone. It will sit in the place where the current fgdata (with all the airplaines) sits and replace that. For that, you will have to move the old fgdata to a place elsewhere. And if you don't have any local branches on it, you can already delete it. If you have local changes, you will have to prepare patches between current master-tip and your local branch-tip, and apply these patches to the new fgdata master-tip. The following repositories are the aircrafts. You will have to clone every aircraft which you would like to have as a git repository. And you should clone them into a different directory than fgdata (strongly recommented). If you want all aircraft, you will have to clone all aircraft. These are the simple facts. - For your convenience, here is a script which pulls and updates all aircrafts from our central repository which you would like to have. In order to use it, you need to create a textfile into which you put the names of all aircrafts which you would like to have. Each name into its own line. Example - an2 21 747 b29 - Then you run this script like this $ ./fgaircrafts path to list path to aircraft directory Example: $ ./fgaircrafts list.txt /usr/local/flightgear/aircraft Those aircrafts which have already been cloned will be pulled, those which are not yet there will be cloned. Note: The script operates on the repositories in parallel, so don't expect any readable output on the commandline. Script Attached #!/bin/bash if [[ ! -f $1 || ! -d $2 ]] ; then echo Usage: $0 listfile target listfile File with names of aircrafts to manage, one aircraft per line targetDirectory into which to put the aircrafts exit 1 fi ( cd $2 while read ac ; do ( if [[ -a $ac ]] ; then if [[ -d $ac ]] ; then cd $ac git pull fi; else git clone git://gitorious.org/flightgear-aircraft/$ac.git fi ) done 3 ) 3$1 -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Ciosco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FGData Split Completed - a.k.a. Life after
On Wed, Oct 19, 2011 at 04:55:28PM -0400, Jacob Burbach wrote: On Wed, Oct 19, 2011 at 3:49 PM, Martin Spott martin.sp...@mgras.net wrote: Jacob Burbach wrote: Seems like most people are just banging their heads against the wall trying to make a new system the same as the old, which is counter productive and unfortunate. I wonder by which justification you pretend to speak for a group whose common understanding you never bothered to share !? Martin. I speak for no person and no group, nor do I pretend to do so. I speak only about a general recurring theme in this discussion in which many seem to be struggling to find a simple, hands free way to get a monolithic fgdata back. Sure, some may have some use or actual need for it, but it really seems many are searching for a problem that doesn't really exist as such. cheers --Jacob Dear Jacob, if you had followed the discussion a bit more attentively and in particular read my two emails, you would know that everything, apart from the tiny issue with the fgdata-core repository, which by now has been rectified, everything goes flawlessly (and according to the plan which has been made in advance, which you don't know about). I don't think anyone is really looking for a a way back, by now practically everyone has realized that the split was necessary. Yes, this was a change. And perhaps an at first confusing change for those not well aquainted with Git and the structure of fgdata, but even they will get used to it. If there are currently still problems with the change, they either result from the unknowingness of the respective people, which can easily be remedied, or bugs which has been revealed through the split (such as the use of wrong file-paths in some of the airplanes). regards, ManDay -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Ciosco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Ciosco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] FGData Split Completed - a.k.a. Life after the Split
= IMPORTANT NOTICE TO EVERYONE INVOLVED WITH THE DEVELOPMENT OF FGDATA OR AIRPLANES THEREIN = Thanks to the concentrated effort of all people involved, most notably Jorg - who I'd hereby like to thank on behalf of all of us, for spending three successive days and nights branching, cloning, filtering, splitting and verifying data - FGDATA has, by today, successfully been split into individual repositories, comprising the respective planes and FGDATA core data. Again: === !!! === From the present day on, the development version of FGDATA NO LONGER CONTAINS ANY AIRPLANES - You will have to clone a new FGDATA! === - Airplanes migrated - All airplanes, hitherto found in $FGDATA/Aircraft/, have been removed from that place in the development version of FGDATA and can presently be found in their individual repositories at the following URL https://gitorious.org/flightgear-aircraft (Disclaimer: HTML page is rather huge) Please contact either of the following administrators to be given priviledges on one of those repositories: https://gitorious.org/+flightgear-aircraft/memberships - New FGDATA Core - FGDATA is now without any aircraft. The only things which remain in FGDATA's Aircraft directory are general purpose data which are used by a bulk of different airplanes. The respective directories of these data are Generic Instruments Instruments-3d Despite its name, now a historical relict, NO AIRCRAFT SHALL EVER BE PUSHED TO $FGDATA/Aircraft. The new FGDATA can be found in the official repository at the following URL https://gitorious.org/fg/fgdata-new The repository is named fgdata-new for the time being and the old fgdata is kept arround, frozen, to have a fallback if anything should happen. Please contact either of the following administrators to be given priviledges on the new fgdata repository: https://gitorious.org/+flightgear-developers/memberships - Development - All aircraft related development shall henceforth be performed on repositories which are maintained by the respective authors. It is planned that most of the repositories on https://gitorious.org/flightgear-aircraft will be dissolved over time and be taken over by the respective authors. On a sidenote, some of those repositories are already superflous because development has long been moved somewhere else. These are the first repositories which will be decomissioned. Only repositories for which no author is found will remain stored centrally. Development on the rest of FGDATA will continue in the new FGDATA repository until further notice, possibly until more components are migrated, as it has been brought forward. https://gitorious.org/fg/fgdata-new - Usage - To keep up with the new structure, commit all your local changes on your old FGDATA and move its directory out of the way (for example by renaming it). $ cd fgdata $ git commit -a $ cd .. $ mv fgdata fgdata-OLD Next, clone the new repository of FGDATA $ git clone git://gitorious.org/fg/fgdata-new.git fgdata IF YOU HAD LOCAL CHANGES, you will need to reapply these changes. This could be a little adventurous, because these are actually two separate repositories and you can't just rebase. You'll have to prepare the patches and apply them over. If you need help with this, check on the official IRC channel at irc://irc.flightgear.org/flightgear for help. Now you have the new core FGDATA (possibly with your own changes, if you followed the hint above). In the coming days, we will provide you with scripts which conveniently fetch your personal selection of aircrafts; until then you will have to manually obtain them from the repositories. Here is how: DO NOT PUT THE AIRCRAFTS INTO THE NEW FGDATA! Instead, create a new directory somewhere completely different, say, /usr/local/flightgear/aircrafts and store the aircrafts in there (for example clone them from their repositories). If you specify that directory on the command line to Flightgear, it will find them, altough they are not in the FGDATA directory. E.g.: $ ./fgfs --fg-aircraft=/usr/local/flightgear/aircrafts NOTE: Some aircrafts explicitly require to be inside of FGDATA, because they are programmed to expect their own data files to be found in FGDATA. These airplanes will give you an error if you put them outside of FGDATA (as you must). In order to solve this, you can symbolically link them individually into FGDATA (Git is already told to ignore those links). $ ln -s /usr/local/flightgear/aircrafts/c172p /path/to/fgdata/Aircraft/ === If you are experiencing problems you can find people who can help you on IRC. regards, ManDay, on behalf of the Split-Team ^^ -- 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
Re: [Flightgear-devel] FGData Split Completed - a.k.a. Life after the Split
On Tue, Oct 18, 2011 at 05:33:23PM +0100, Stuart Buchanan wrote: On Tue, Oct 18, 2011 at 5:24 PM, Cedric Sodhi wrote: NOTE: Some aircrafts explicitly require to be inside of FGDATA, because they are programmed to expect their own data files to be found in FGDATA. These airplanes will give you an error if you put them outside of FGDATA (as you must). In order to solve this, you can symbolically link them individually into FGDATA (Git is already told to ignore those links). $ ln -s /usr/local/flightgear/aircrafts/c172p /path/to/fgdata/Aircraft/ === Surely that would be a bug in the aircraft that should be fixed? Indeed. Also, IIRC there are a number of aircraft that have dependencies on other aircraft. Presumably this would be a good opportunity to fix those as well? Agreed. ManDay -Stuart -- 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-oct ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear aircraft repository
On Tue, Oct 18, 2011 at 09:46:58PM +0200, Gijs de Rooy wrote: Hi all! Cedric wrote: ManDay, on behalf of the Split-Team ^^ ThorstenB wrote: I don't think this is what we agreed upon. I'd like to mention that Cedric did not wrote his email on my behalf nor on Jorg's. Hello, I apologize for wrongly inserting the suggestion to dissolve the repos on your behalf. I think the other parts of the E-Mail, the description etc, were very well composed on your behalf, though. As for the topic brought up here, I sense a bit of sentimentalism clouding the technical judgment of some. Fact is, that quite a few aircrafts of the old FGDATA are nowadays developed elsewhere. I recall at least having witnessed this twice, although I've only tried a few airplanes. If I recall correctly, skyop's magnificant Bombardier is one of those planes which are developed launchpad and is only represented in FGDATA-Airplanes for historical reasons. Regardless, your arguments why a central repository would be an advantage, minus the sentimental it has always been like that parts, esp. the one about authors joining and leaving, are more or less orthogonal to the philosophy of the development structure which you employ: Git and Gitorious. A central facility, which collects all planes, yes, that makes sense. Actually, I see not how such thing could possibly be forgone. But forcing all aircraft development under the patronage of the core developers is without any practical footing. You are not helping anyone, nor are you supporting GPL. If people want to publish under the GPL, they will do so. If not, they wont. Regardless of whether you coerce them to publish their planes in your master-repository, but only as GPL. Neither do you provide any more guarantee by herding developers into your central repository. You are only patronizing them. You cannot guarantee for someone else's property. And if it's not their property for it's GPL, you can always keep yourself a backup-copy or a clone of their repository, if you are worried about guarantees. Not only are all these alleged advantages pretty much contrived, there are also disadvantages in urging people to play in your opera rather than their own. Restrictions are always harmful to voluntary work. If I, for example, am a LP user and you are trying to lure me come, come to us, here is where the good things happen to your repository, I will rather turn away - as opposed to an OPEN development structure where people are encourage to develop whereever, however they want and simply announce their contribution centrally. History has shown what that concept of a centralized master-repo has lead to: A thick jungle of half-finished, unmaintained and completely abandoned planes, happily mixed with high-quality planes, relicts of planes which have long been migrated to development elsewhere and practically everone has lost orientation in your master-repo. This is not how Git works. This is not how modular contribution on open software works. This is not how Gitorious works. It's most likely counter productive, as has been the unnavigable jungle of planes in the first place. In a positive creative development structure you leave the contributors their freedom. Contribute your planes! rather than Come to Gitorious, ask for our permission to get your repository, work under our supervision! Work, work, my busy bees, and make us planes for our big master-repository! ...to be equally provocative. kind regards, ManDay -- 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-oct ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] GIT
You may have guessd what this is about: FGDATA and GIT. When we last spoke about it, everything had been prepared to the utmost convenient state possible. I had prepared a script which basically only has to be run, to migrate the truckload of planes, ranging from fine stuff to utter junk, into separate repos, which from then on could be maintained by their respective autors - separately from FGDATA. Since then... ...nothing happened. Developers have buoyantly indulged in their lethargy as ever before and passionately ignored the topic wherever it came up. I must say that even I have a limited amount of patience. And that amount - already accounting for the fact that I'm not a vivid contributer as others and might thus have less of a right to request something from the core team - is about to be depleted by the striking ignorance that is portrayed among those responsible. You want people to help with the development of flightgear, in every area they can? And this is how such help is recognized? Very well understood. I'll let this be my last mail to the list and last time I even remotely mention the topic anywhere. You can see for yourself and wait until that pile of crap hits the ceiling. I'm done with trying to fix it in time, for I'm sick begging you to accept my help. not so kindly, ManDay -- 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-oct ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FGData New Structure
Dear everyone,
a day late and I must admit the first version of the script really
wasn't what it was supposed to be, but here is the final version now.
Verified and tested on a small reproduction of FGData, example repo has
been uploaded[1].
The instructions have changed, no more tmpfs is required. Just browse
into your FGDATA, make sure the working dir is clean, and run the script
(which necessarily lies outside of the FGDATA dir).
There is one tiny problem which I was not entirely able to solve, that
is that not all tags appear to be sucessfully transfered. I must insist
though, that this is a negligible issue and given the project at hand,
clearly acceptable. In the worst case we will have to reset the few tags
on FGDATA were required.
In order to run the script on the example repo instead of the real
fgdata to check for yourself, you will have to change the settings
ac_dir and canonical as indicated in the first lines of the script to
the commented-out versions.
[1] http://ompldr.org/vYWZydg
#!/bin/bash
iodir=/tmp/fgsplit
final_ac=../split_airplanes_result/
final_fg=../split_fgdata_result/
ac_dir=Aircraft
canonical=origin/master
#canonical=master
#ac_dir=Aircrafts
#dornot2d=-d $iodir
bare=--bare
echo
Splitting FGDATA in 10 Seconds - Press Ctrl-C to cancel!
WARNINGS
Make _ABSOLUTELY SURE_ that you are in the right repository
Running this script in a wrong repository will have unpredictable
results!
Make sure to have $iodir mounted as tmpfs with all the storage
that you can spare, at least the size of the tree, which is 6GB
All data in the following directories will be purged, if they
already exist:
$final_ac $final_fg
NOTE
_NO_ irreversible changes will be made to your local repository
The resulting 'split' repositories after the spit can be found in
$final_ac
and
$final_fg
If satisfied with the results you can then delete this very repo
Which will, of course, seal the deal and make it irreversible
sleep 10;
if ! git status ; then
echo ERROR - Please navigate into the root of the FGDATA repository
exit
fi
echo Removing $final_ac $final_fg and $iodir
rm -RI $final_ac $final_fg $iodir
mkdir -p $final_ac $final_fg
origin=$(pwd)
sleep 1
echo Bringing up to date
git pull
echo Going onto canonical master
git checkout $canonical
echo Creating branches for all aircrafts
for acf in ./$ac_dir/* ; do
ac=${acf#./$ac_dir/}
acbn=SPLIT-$ac
if [[ $ac == Generic || $ac == Instruments || $ac ==
Instruments-3d ]] ; then
echo Skipping $ac
continue ;
fi
echo Going onto canonical master
git checkout $canonical
echo Branching for $ac ;
git branch $acbn
echo Switching to new branch;
git checkout $acbn
echo Isolating, please wait;
git filter-branch -f $dornot2d --subdirectory-filter $ac_dir/$ac
(
echo Extracting into new repository
cd $final_ac
mkdir $ac
cd $ac
git init $bare
git fetch $origin $acbn
git branch master FETCH_HEAD
)
done
echo Going onto canonical master
git checkout $canonical
echo Branching for reduced FGDATA
git branch SPLIT-CORE
git checkout SPLIT-CORE
echo Isolating, please wait
git filter-branch -f $dornot2d --index-filter git rm --cached --ignore-unmatch
$ac_dir/*
cd $final_fg
echo Extracting into new repository
git init $bare
git fetch $origin SPLIT-CORE
git branch master FETCH_HEAD
echo Done. Please verify the results.
--
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-d2dcopy1___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FGData New Structure
Hello everybody, I'll keep this message as short as I can for some reason: We have built a script which will extract all Aircraft/* apart from Generic, Instruments and Instruments-3d into separate, cleaned up repositories and also extract the clean fgdata. The script is attached. Now we need to ask you the following: The problem we have is that this script cannot be ran on Gitorious directly. For one, because we don't have the required shell access there and second, because the operations required to perform the split put a tremendous load on I/O and CPU. With the size of FGDATA it would be impossible to perform the operation on the Gitorious servers. We need someone to run this script locally and then clone the result(s) onto gitorious. For that you require - Linux and root access (in order to mount a tmpfs) - A good amount of RAM (at least 6 Gigabytes) - A decent CPU - Patience - A stable PC - and finally a stable internet connection to be able to clone the results into Gitorious - And possibly patience if the script fails to have me make the necessary adjustments. The script does not perform any irreversible operations and will certainly not cause any damage (it is very simple and linear, you might look at it yourself), however, I can of course make no guarantee for anything so you best don't run it on a repository which has pending commits to be pushed. If you are willing to do this (I cannot do this for I fall short of a stable inet connection), you must read the following. Some preps are in place: You need to mount /tmp/fgsplit as a tmpfs with at least 6 gigabytes ram. This is not strictly required but otherwise you would have to straing your HDD with an enourmous amount of IO. After you mounted that, navigate to your fgdata directory (as user, you only need root for mounting the tmpfs) and run the script from there. possibly press Ctrl-C on the first run to read the message that comes up. Make sure you run the script on a fully committed working copy. If everything succeeds as planned, which could take many hours, the results can be found one directory up (as described in the message) and your current fgdata will have a bunch of new branches which you can delete, which will return your repo to the old state. You may eventually delete your old (then untouched) fgdata and clone the results to gitorious. The script itsself uses just basic git commands to extract the various parts into the target directories and leaves master of your current FGDATA unaffected. any questions feel free to ask or join on IRC (I'be there arround 1800 GMT) The principle of the script has been tested on a small scale repository and it should therefore work. Failure is absolutly possible, if not likely, but the worst thing that may happen is that it doesnt start properly for one or another reason. best thing you can do is look at the script yourself and see what it does. I'd be glad if we could eventually get this done. Thank you, regards, ManDay -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA http://p.sf.net/sfu/rim-devcon-copy2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FGData New Structure
... And here is the script
#!/bin/bash
echo 'Splitting FGDATA in 10 Seconds - Press Ctrl-C to cancel!'
echo ' WARNING '
echo 'Make _ABSOLUTELY SURE_ that you are in the right repository'
echo 'Running this script in a wrong repository will have unpredictable'
echo 'results!'
echo ' NOTE '
echo '_NO_ irreversible changes will be made to your local repository'
echo 'The resulting split repositories after the spit can be found in'
echo ' ../split_fgdata_result/'
echo 'and'
echo ' ../split_airplanes_result/'
echo 'If satisfied with the results you can then delete this very repo'
echo 'Which will, of course, seal the deal and make it irreversible'
sleep 10;
if ! git status ; then
echo ERROR - Please navigate into the root of the FGDATA repository
exit
fi
final_ac=../split_airplanes_result/
final_fg=../split_fgdata_result/
mkdir $final_ac
mkdir $final_fg
origin=$(pwd)
sleep 1
echo Bringing up to date
git pull
echo Going onto canonical master
git checkout origin/master
echo Creating branches for all aircrafts, hang on
for acf in ./Aircraft/* ; do
ac=${acf#./Aircraft/}
if [[ $ac == Generic || $ac == Instruments || $ac ==
Instruments-3d ]] ; then
continue ;
fi
echo Going onto canonical master
#git checkout origin/master
echo Branching for $ac ;
acbn=SPLIT-$ac
git branch $acbn
echo Switching...;
git checkout $acbn
echo Isolating...;
git filter-branch --subdirectory-filter /Aircraft/$ac
(
echo Creating new (bare) repository for $ac...
cd $final_ac
mkdir $ac
cd $ac
git init --bare
echo Extracting...
git fetch $origin $acbn
git branch master FETCH_HEAD
)
done
echo Going onto canonical master
git checkout origin/master
echo Branching for reduced FGDATA
git branch SPLIT-CORE
echo Reducing...
git filter-branch --index-filter 'git rm --cached --ignore-unmatch /Aircraft/*'
(
cd $final_fg
echo Creating new (bare) repository for fgdata
git init --bare
echo Extracting...
git fetch $origin SPLIT-CORE
git branch master FETCH_HEAD
)
echo DONE
--
BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA
http://p.sf.net/sfu/rim-devcon-copy2___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FGData New Structure
I'm afraid I attached the wrong version, here is the correct one.
#!/bin/bash
iodir=/tmp/fgsplit
echo 'Splitting FGDATA in 10 Seconds - Press Ctrl-C to cancel!'
echo ' WARNING '
echo 'Make _ABSOLUTELY SURE_ that you are in the right repository'
echo 'Running this script in a wrong repository will have unpredictable'
echo 'results! FURTHERMORE make sure to have'
echo $iodir
echo 'mounted as tmpfs with all the storage that you can spare'
echo ' NOTE '
echo '_NO_ irreversible changes will be made to your local repository'
echo 'The resulting split repositories after the spit can be found in'
echo ' ../split_fgdata_result/'
echo 'and'
echo ' ../split_airplanes_result/'
echo 'If satisfied with the results you can then delete this very repo'
echo 'Which will, of course, seal the deal and make it irreversible'
sleep 10;
if ! git status ; then
echo ERROR - Please navigate into the root of the FGDATA repository
exit
fi
final_ac=../split_airplanes_result/
final_fg=../split_fgdata_result/
mkdir $final_ac
mkdir $final_fg
origin=$(pwd)
sleep 1
echo Bringing up to date
git pull
echo Going onto canonical master
git checkout origin/master
echo Creating branches for all aircrafts, hang on
for acf in ./Aircraft/* ; do
ac=${acf#./Aircraft/}
if [[ $ac == Generic || $ac == Instruments || $ac ==
Instruments-3d ]] ; then
continue ;
fi
echo Going onto canonical master
#git checkout origin/master
echo Branching for $ac ;
acbn=SPLIT-$ac
git branch $acbn
echo Switching...;
git checkout $acbn
echo Isolating...;
git filter-branch --subdirectory-filter /Aircraft/$ac
(
echo Creating new (bare) repository for $ac...
cd $final_ac
mkdir $ac
cd $ac
git init --bare
echo Extracting...
git fetch $origin $acbn
git branch master FETCH_HEAD
)
done
echo Going onto canonical master
git checkout origin/master
echo Branching for reduced FGDATA
git branch SPLIT-CORE
echo Reducing...
git filter-branch --index-filter 'git rm --cached --ignore-unmatch /Aircraft/*'
(
cd $final_fg
echo Creating new (bare) repository for fgdata
git init --bare
echo Extracting...
git fetch $origin SPLIT-CORE
git branch master FETCH_HEAD
)
echo DONE
--
BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA
http://p.sf.net/sfu/rim-devcon-copy2___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FGData New Structure
Hopefully the right version now. Had to add something.
#!/bin/bash
iodir=/tmp/fgsplit
echo 'Splitting FGDATA in 10 Seconds - Press Ctrl-C to cancel!'
echo ' WARNING '
echo 'Make _ABSOLUTELY SURE_ that you are in the right repository'
echo 'Running this script in a wrong repository will have unpredictable'
echo 'results! FURTHERMORE make sure to have'
echo $iodir
echo 'mounted as tmpfs with all the storage that you can spare'
echo ' NOTE '
echo '_NO_ irreversible changes will be made to your local repository'
echo 'The resulting split repositories after the spit can be found in'
echo ' ../split_fgdata_result/'
echo 'and'
echo ' ../split_airplanes_result/'
echo 'If satisfied with the results you can then delete this very repo'
echo 'Which will, of course, seal the deal and make it irreversible'
sleep 10;
if ! git status ; then
echo ERROR - Please navigate into the root of the FGDATA repository
exit
fi
final_ac=../split_airplanes_result/
final_fg=../split_fgdata_result/
mkdir $final_ac
mkdir $final_fg
origin=$(pwd)
sleep 1
echo Bringing up to date
git pull
echo Going onto canonical master
git checkout origin/master
echo Creating branches for all aircrafts, hang on
for acf in ./Aircraft/* ; do
ac=${acf#./Aircraft/}
if [[ $ac == Generic || $ac == Instruments || $ac ==
Instruments-3d ]] ; then
continue ;
fi
echo Going onto canonical master
#git checkout origin/master
echo Branching for $ac ;
acbn=SPLIT-$ac
git branch $acbn
echo Switching...;
git checkout $acbn
echo Isolating...;
git filter-branch -d $iodir --subdirectory-filter /Aircraft/$ac
(
echo Creating new (bare) repository for $ac...
cd $final_ac
mkdir $ac
cd $ac
git init --bare
echo Extracting...
git fetch $origin $acbn
git branch master FETCH_HEAD
)
done
echo Going onto canonical master
git checkout origin/master
echo Branching for reduced FGDATA
git branch SPLIT-CORE
echo Reducing...
git filter-branch -d $iodir --index-filter 'git rm --cached --ignore-unmatch
/Aircraft/*'
(
cd $final_fg
echo Creating new (bare) repository for fgdata
git init --bare
echo Extracting...
git fetch $origin SPLIT-CORE
git branch master FETCH_HEAD
)
echo DONE
--
BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA
http://p.sf.net/sfu/rim-devcon-copy2___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FGData New Structure
Right. I've been a bit sloppy when I wrote this yesterday. I'll rewrite it in a more proper and failsafe manner today. You might want to want to wait until then. On Mon, Sep 19, 2011 at 12:21:40AM +0200, Arnt Karlsen wrote: On Sun, 18 Sep 2011 23:07:48 +0200, Cedric wrote in message 20110918210742.GA11631@engine: We need someone to run this script locally and then clone the result(s) onto gitorious. For that you require - Linux and root access (in order to mount a tmpfs) ..some of your script echo statements are unquoted, some single quoted and some double quoted. Probably works ok on GNU/Linux, (I'm on the road with a wee ass eeepc looking for a new home for my gasifier and my FG igloo) but I dunno about the other platforms, maybe play it safe and use double quoted echo statements? - A good amount of RAM (at least 6 Gigabytes) - A decent CPU - Patience - A stable PC - and finally a stable internet connection to be able to clone the results into Gitorious -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA http://p.sf.net/sfu/rim-devcon-copy2 ___ 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 Learn about the latest advances in developing for the BlackBerryreg; mobile platform with sessions, labs more. See new tools and technologies. Register for BlackBerryreg; DevCon today! http://p.sf.net/sfu/rim-devcon-copy1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] FGData New Structure
Dear Everyone, I hope this is the last time we will have to discuss this topic, since over the last months it seemed that everyone agreed with that FGDATA - has to be split sometime - should be split a.s.a.p. We agreed that after the current release of 2.4 would be a good point to get the project on the way. As I offered and it still stands, I will take care of writing the bash script which splits the current FGDATA repository into multiple repositories and leaves an FGDATA repository which holds merely the bare essentials which supplement the core binary of fgfs. One could classify the contents of the new FGDATA by saying that it's data which provides the technical backbone - the common denominator everything is based upon. I'd like to cease this opportunity to give everyone the chance to utter their possible disagreement with the project or their respective opinions and discuss the very details of the split, which have not yet been determined. The general boundary conditions of the splitting process are the following: - FGDATA shall consist of everything which is essential for the binary to run and shall not hold any data which is specific to certain airports or airplanes. Those should be provided in separate repositories the structure of which is not of current interest and might possibly be chosen by the respective authors. - The change shall not require restructuring of the architecture, including the directory structure. Solely the repositories in which the data is contained shall change. Informatively, I'd like to supply a sensible suggestion for how a final structure might look and how, either as a developer or user might use it. Particularily, because some of you might wonder how we can strip FGDATA of KSFO and the 172p, leaving nothing to fly with - isn't that a bad decision? Definitly not. One has to distinguish between a proper, dedicated development structure which is aligned to and substructred into independent development units and a way of deployment. As a developer, you will clone the base fgfs SC repository and you will clone the FGDATA repository. Then, depending on your field of interest you will clone the aircrafts, airports etc. you are planning to work on. You can do so with the git submodule, which will integrate the specific aircraft/airport/etc repository into the existing FGDATA repository, while keeping the commits separate. For deployment, you either manually or programatically git-submodule all data required for shipping into a branch for deployment. This includes, for instance, the KSFO tile and the c172p. It's apparent that one, among many advantages of that approach is, that the confusing redundancy between the default KSFO and the scenery KSFO, as it currently exists, will go. While the planes are the primary concern of the splitting and will bring a relief of a tremendous 4.5 Gigabytes to every user of FGDATA and rectify a lot of redundancies and confusion, other things might also be considered, say, ./Traffic (just a lucky guess). Practically everything which is orthogonal to the core and without which FG (assuming a plane and a tile) can properly run, should migrate. regards, ManDay -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA http://p.sf.net/sfu/rim-devcon-copy2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Former AI Plans - revived?
Hello, I'm ManDay (It has been critizised that I did not choose my nickname as a listname, so I wanted to tell you who I am, in case you didn't know). Just today, I received a PM from Hooray on the forums, mentioning my draft proposal for a strategy to implement AI ATC in Flightgear. Sadly, the thread received little feedback back then. Durk, to my knowledge, was still somewhere on the move, too. Meanwhile, so I've heard, he has made some efforts to implement basic ATC with takeoff permission, so I've understood. Nevertheless I'm still convinced of the proposal I've made and I was hoping that you might revisit and reconsider it - possibly giving feedback on how eligible you deem it. http://flightgear.org/forums/viewtopic.php?p=115173 regards, ManDay -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA http://p.sf.net/sfu/rim-devcon-copy2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Splitting fgdata
I appreciate your effort Roland. I hope this workarround doesn't take the momentum from the original endeavor, though. On Thu, Apr 21, 2011 at 12:17:43AM +0200, Roland Häder wrote: Hi, I have updated my little website, plus the fgdata.bundle and all checksum files and signature. I will try to add a shell script to automatically recreate the bundle including all checksum files (signature is STRONGLY not recommended with automatism because you need give the server your private key and that will compromise it). Regards, Roland On Thu, 2011-04-21 at 00:26 +0200, Csaba Halász wrote: On Wed, Apr 20, 2011 at 11:05 PM, Arnt Karlsen a...@c2i.net wrote: ..should say: wget -c \ http://flightgear.mxchange.org/pub/fgfs/fgdata.bundle so the download can be resumed if it stalls or somesuch, rather than try wget the whole bundle into fgdata.bundle.1, fgdata.bundle.2 because etc those widely documented writings aren't as widely read. ;o) PS: installed nouveau, not much luck with it yet PS: Still good luck with it. :) I saw it is experimental. -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
