Re: Issues updating planes located in FGAddon

What I'm saying is, we should not be afraid to make it hard to apply

> search-and-replace operations across the whole set

because once that becomes hard, we will be forced to think of solutions to
avoid making that necessary.

Am Di., 2. Juni 2026 um 20:20 Uhr schrieb Frederic T. <
[email protected]>:

> > I’d prefer we get some tooling in place to allow at least
> search-and-replace operations across the whole set, working on eg
> instrument changes or AP changes without that would be more error-prone.
>
> If we need to do that, we did something wrong, and we are doing it wrong
> since the beginning - instruments / APs / etc. should not be copied into
> every aircraft but at the very least be in a separate repository integrated
> into the aircraft as a git submodule, or even better we have a framework
> that allows integration of instruments etc. from a repository like FGAddon.
>
> Am Di., 2. Juni 2026 um 18:58 Uhr schrieb James Turner <
> [email protected]>:
>
>>
>>
>> On 1 Jun 2026, at 23:00, Josh Davidson <[email protected]>
>> wrote:
>>
>> How about a git organization with planes as sub-repos? That shouldn't be
>> a problem at all. (Suggested to me by a private email)
>>
>>
>> That is possible but needs (I think) the following:
>>  - get permission from GitLab (formally, eg in writing) that a group/org
>> with 200+ repos is valid use of their SaaS service, and they won’t consider
>> it abuse.
>>  - apply for an open-source org (like we do for Flightgear already) for
>> that group (I could help with that, but we need to show that every repo is
>> license compatible, and do some other house-keeping)
>>  - have scripts that extract aircraft from the svn history and create
>> corresponding projects/repos **with Git LFS enabled**.
>>
>> (The LFS part is really important, to make the checkout experience ok)
>>
>> And having done that, we would have 200+ discrete repos: so no way to
>> grep / modify multiple aircraft at once. I’d prefer we get some tooling in
>> place to allow at least search-and-replace operations across the whole set,
>> working on eg instrument changes or AP changes without that would be more
>> error-prone.
>>
>> What we can’t do is make them all submodules of one super-repo, I think
>> that will be just as slow / bad to checkout as the current SVN, or close to
>> it. (My experience is more than 10+ submodules is asking for trouble)
>>
>> However, if we do that, there is no reason to have a GitLab repo for eg
>> the A320 or C172, since we’re just mirroring a repo that exists elsewhere
>> (on GitHub or anywhere else); I think we may as well have the Fgaddon
>> catalog builder just pull from the primary repo for each aircraft.
>>
>> There’s also the user education part of this, we’re changing the workflow
>> and tooling for a bunch of people, many of whom are not ‘coders’. Concepts
>> like push-ing and rebasing are going to need some hand-holding for them, I
>> expect, and the state of Windows GUI git-clients is a bit tricky, to put it
>> mildly.
>>
>> I’d be curious to hear from Torsten D, who did the private negotiations
>> with SF originally to be allowed the current SVN setup, if the above seems
>> feasible, since this is all just based on my experience.
>>
>> Kind regards,
>> James
>>
>> _______________________________________________
>> Flightgear-devel mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
>>
>

_______________________________________________
Flightgear-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/flightgear-devel