In a future post, I would love to see a discussion of organizing your software abstractions, rather than just organizing files. For example, id love to know some ideas around keeping prior versions of structs around when you are partially upgrading some schema or other. Or about when to use macros to automate in-repo cleanups.
Rust is definitely a beast when managing 200K+ LOC codebases and just managing compiler woes becomes a challenge. Not to mention dealing with issues with compiler targets, feature flags, etc. It definitely goes deeper than file structure.
We've done large schema migrations in a 1 million LoC Rust codebase. Most of the time, these are pretty straightforward. You mark things as deprecated and link a tracking ticket for the migration in the doc-comment of the field/struct.
What's a lot more difficult is making sure migrations don't break important forwards/backwards compatibility guarantees. Unfortunately, Rust won't help you much with these. One solution we've been using in our team to get confidence in the correctness of our schema evolution is to use proc-macros to generate a somewhat exhaustive set of test data, so that every field and enum variant is included at least once. In CI we test the branch version against master, and let each version serialize/deserialize the other version's test cases.
Rust is definitely a beast when managing 200K+ LOC codebases and just managing compiler woes becomes a challenge. Not to mention dealing with issues with compiler targets, feature flags, etc. It definitely goes deeper than file structure.