10.16.2026
I've been thinking about this for a while, and it's time I finally rip off the bandaid, so to speak. Since Kohi's inception, it's been souce-controlled via git, specifically on GitHub. It's worked okay, but I've always felt that there's something better out there. After much trial and error, I've found that thing.
That thing is Subversion, a type of source-control that was popular before the rise of Git.
Now, if you prefer Git, that's fine. To each their own, but my opinion of this has changed as of late, and my preference has changed.
A few reasons. The new job I started almost a year ago makes use of SVN. So, I had to re-familiarize myself with it after not having touched it in almost two decades. At first, I was like, "Yeah, Git's totally better". But after a while of using SVN, truly using it, my perspective began to shift.
It's simpler to use, for one. There's less steps involved. With Git, you stage your changes with git add . or git add <filename>, then you commit with something like git commit -m "I said forget about it, cuh.", followed by a git push to push those changes up to the remote, assuming the branch already exists, etc.
With SVN, that's all done in a single command, or two at most. If the file hasn't yet been added to the repo, you will need to do svn add <filename> or svn add * if you want to add all files not already added. But if it has already been added, then the only thing you will need to do is svn commit -m "Ejecto seato, cuz!" and you're done.
It also handles binary files much better than git, or even git-lfs.
Subversion also allows you to checkout a specific folder from a different branch, otherwise known as a partial checkout. So if you have a subfolder in repo/foo/bar and you wanted to just change the bar folder to another branch without chaning over everything else, you can. Just make sure you're browsed to the folder when you do svn switch.
The GutHub repo isn't going anywhere. I'll just be moving releases only to it after this point, not work-in-progress. So the GitHub repo is essentually going to become an occasionally-updated snapshot of what's going on, but the real bleeding-edge updates will be in the SVN repo.
Simply put, it can be found over at https://svn.kohiengine.com/svn/kohi. The bleeding-edge code will be found in trunk. Note that I have not carried over all the history from GitHub here to this repo. SVN requires a linear history, and the git repo does not have this. I've tried to port it over, but it just wasn't working because of the complicated history of the project. Therefore, this revision counter is far less than the original number of commits on git. It is what it is.
I essentially ported over the branches of code (or snapshots) of the released versions of the codebase from 0.6 onward, but in a flattened/squashed format that encapsulates all of the changes up to that point in a single SVN commit. If you want the history, the GitHub repo isn't going anywhere.
The branching strategy will be changing too. Up until now, in Git, a release branch was created from main, and all changes to be associated with that release are checked into that branch, say release/v0.13.0. When that version is ready to "ship", it is merged into main, then a tag is created for the release, and the branch is then locked down.
The new strategy will be sort-of the opposite. Development will be done directly in trunk, and once a version is ready to be cut, a new tag will be created for that version, which is also effectively a branch of the code at that point. For example, tags/release-v0.13.0 will be the 0.13 release. 0.13 is the last release being done the old fashioned way.
From this point on, all bleeding-edge development will be done against trunk or a short-lived feature branch, and then that feature branch will be merged into trunk, which will eventually be cut into a release tag.
TL;DR - you can't. For now.
In the short term, contributions to the codebase won't be possible directly, at least not through GitHub. The GitHub repo will only recieve periodic, manual updates from SVN as I deem necessary to push them over. Pull requests won't be accepted there any longer from this point on, at least not directly.
If you'd like credit for a change, I can add your name or username to a credits file to ensure it's there. Past contributions will be honored this way.
This sort-of points to where I am taking things in the future though, in that I am not currently looking for contributions to the codebase directly. There have been a lot of automated requests coming through, as seems to be the case with a lot of open source projects, and ones that aren't up to the standard I'd like to set for this project going forward. Therefore, pull requests can be used from here on out to suggest changes, but they won't, and cannot be, accepted since GitHub is no longer the source of truth.
I will eventually be locking down the GitHub repo for Issues and PRs for these reasons.
I've still got a lot to figure out with all of this, so much that is mentioned here is subject to change. Keep an eye out here and on the forums for updates.
Thanks for reading this, and thanks for being here. See you soon for the next update!
See Also: