Jump to content
  • KSP meets Git!


    HarvesteR

    Up until now, we've been using SVN for version control. SVN is ok, but 'ok' isn't quite good enough....

     

    Git on the other hand, is awesome.

     

    691k6.png

     


    If you're not a developer or version control enthusiast, here's the backstory: Git and SVN are version control systems. They allow multiple developers to work together over a single project, letting us manage revisions, commit changes, and generally work over the same files without making a huge mess of things.

     

    We've used SVN on KSP so far, and SVN, while simple to use, has some limitations that can turn into big issues as the project becomes larger and more people start working on it.

     

    For instance, in SVN, everyone commits changes to the same repository, which means if I change a piece of code that creates a gamebreaking bug and commit that, everyone's game will break as well.

     

    That led us to have to impose rules regarding who can commit and when, to prevent someone committing a gamebreaking bug as the game is under experimental testing, and other such stupidities that come from working with a limited system.

     

    We called that "Feature-Lock". While in Feature-Lock, no one was allowed to commit any changes unless they were bugfixes to the current experimental version. That worked to prevent gamebreaking commits during release times, but it also meant that people who didn't have bugs to fix were restricted from working properly until release time was over... And then their copies would have a huge amount of uncommitted changes to push, and merging all that would be a big problem.

     

    Now, Git is a much more elegant and sophisticated version control system. Unlike SVN, there is no single central repository that receives changes from all users. Git excels at something called 'branching'.

     

    Branching allows someone to work on something, and keep version control of it, without affecting the main version (the 'trunk') for everyone else. SVN has branches too, but in SVN, creating (and later merging) branches is a complicated and failure-prone task.

     

    Git on the other hand, can do this:

     

    Screen-shot-2009-12-24-at-11.32.03.png

     

    This ease to create and merge branches allows us to create branches for each feature. The idea is that every feature we work on, be it a new set of parts, or a new feature to the VAB and SPH, wouldn't exist on the 'trunk' (or "master" in Git) until it is stable enough to be added to the project without creating game-breaking issues. Each feature would live on its own branch, and the master copy would always be kept at a stable state.

     

    This means features become very modular. They don't exist on the release version until they're ready to go, which means if a feature doesn't make it in time for a release, we don't need to do anything to remove or hide the incomplete implementation. We just don't merge the feature branch into the release branch.

     

    It also removes the need for Feature-Lock. When we go into experimentals, we can simply create a new experimental branch, which would only get bugfix commits. Any features that don't make it in won't affect that branch, and they in turn can get the bugfixes implemented for the experimental.

     

    Now that we have some room to breathe again, after the madness that was the 0.18 release timeframe, we set aside some time to do the transition. We had to re-upload the entire project to the new git repo we created on GitHub (it's a private one, we haven't gone open-source)... That took a while, since the KSP project is many GBs now, and we had to reconfigure our build pipeline to use the new Git repo instead of the old SVN one. Took some doing, but it's definitely worth it.

     


    So, what does all this mean for the average KSP player? Well, at first, not much, other than the knowledge that your favorite dev team now has a much better workflow and doesn't have to worry about one dev's work breaking the game for everyone else. :)

     

    In time though, this improved workflow might very well translate into faster development times for features, meaning more features on each update, and less trouble with half-implemented features, meaning less bugs as well.

     

    That's about it... Just wanted to share the news with everyone. :)

     

    Cheers


    User Feedback

    Recommended Comments

    There are no comments to display.


×
×
  • Create New...