Let me list few examples:
- Multiple duels at the same time
- No duplicate names (Padawan, Padawan(1) …)
- wk/nk settings
- emote animations
- all common bug fixes
My idea is to use a VCS like Git as a generic code-reuse solution. This requires a proper workflow and development cycle though. Ideal situation would be having a git repository where you can either merge, cherry-pick features or revert existing ones independently and without conflicts. Is it possible to come even close to this? I have strong doubts about it. I hope we can come to a conclusion in a discussion. Here is what I came up with so far:
If a feature is to be merge/reverted, it would be best to keep all work on it in a single feature-branch. What about single-commit features? There is a strong temptation to put them right on our development branch. What if we need to fix them later? How is a person who wants to merge the feature supposed to know that there is also a fix, possibly many commits later? Keeping EVERYTHING, even single-commits on separate branches seems to be solution, applying fix to it and mergin it back. We may end up with git history looking like this though:
Code: Select all
* |\ * * |\| * * |\| | * |/ *
What about feature dependency though? Single dependency is easy - just start off the feature branch you need. What if we need few features as dependencies? I guess it would be possible by starting each feature off a common core and merging each dependency as needed. It would make for an enormous octopus repo and certainly isn't worth the effort.
Is there even a solution to this problem without sacrificing major ammount of dev time for repo maintanence?
Maybe it would be better maintain a riggid base repo, sort of new sdk, with common set of core features/bugfixes like ioq3 and backport popular features from forked projects?
You can see somewhat "branched" result of my experiments here: https://github.com/aufau/SaberMod/network I don't feel like it's reusable right now, more of a dependency hell. I'm almost certainly gonna rebase these repos in the future.