Am 19.10.2011 20:45, schrieb Jacob Burbach: > 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. It is highly unlikely ANYONE needs every > single aircraft from git that they were previously forced to take, > which is the whole point of the change. If people are honest with > themselves I think they would realize they only need such aircraft > that they plan to use or do development on. Personally I am extremely > happy that I will no longer need to pull down hundreds of aircraft I > have no intention of ever touching just so I can work on and test > development new development in flightgear. Fair point. But some of use might need to walk through all aircraft from time to time. One example: I'm working on a new implementation of the navradio code (the code that does the VOR/LOC/GS computation). I'd prefer to guarantee some degree of backward compatibility with existing aircraft. Which ones should I choose?
Another example: For the last release, we branched and tagged the repositories and well defined states. This was OK for three repositories (fg+sg+fgdata). Doing this manually for 300+ repos is a no and doing this scripted calls for trouble. I'm not saying that the old situation (one single repo) is heaven on earth. But for me as a developer, it has more advantages than disadvantages. I have no issues with the size, I branch, merge, pull and push in seconds. Only, git gc --aggressive takes some time. > > In the end this will make it much, much easier for new developers and > testers to get up and running and get to work. I'm not convinced that this is true. Torsten ------------------------------------------------------------------------------ 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
