When I first saw the full-project .yaml file, I knew it could be parsed, and there would be great value, for the developer, in doing so.
But putting one back together again? In a form Anvil will accept? No, thanks. I’m here to develop apps, not tools for Anvil developers.
Sad to say, you’re right about Git. Version control should be built as the simplest thing that could possibly work, for the task at hand. Maybe something can be built atop Git, for the desktop, to provide a simple, clear mental model (and safer defaults!), but Git itself is anything but.
To be fair, Git was built as a toolkit, to allow solving a vastly larger and more complex problem, with thousands of times as many files, folders, and contributors. The toolkit aspect is no doubt what allowed Anvil to incorporate limited version control into its IDE.
I adopted Git anyway, because it’s (currently) the only way to
- do Search and Replace (the simplest refactoring) across both source code (.py) and forms (.yaml)
- use intra- and inter-project file-comparison tools like WinMerge. (This is critical when you have both a Development version and a Production version, as two separate Anvil apps.)
- copy entire forms from one project to another (your use-case)
- retain additional files (e.g., supporting code, data, and docs) in the project’s folder tree
Git’s anything but foolproof. I still get commands out-of-order. I still screw up a .yaml file here or there, making my entire project un-loadable. But by keeping local backups, I can recover from that, even without understanding the guts of Git.
Overall, even with a bare-bones Git learning curve, the tradeoffs have saved me time. Obviously, a simple, straightforward version-control system would have netted me much more time.
I’m very much in favor of your suggestion. Unlike Git, it very much fits Anvil’s philosophy of keeping things as simple as possible (but no simpler).
