I am here today to announce that the 1000th revision of DoC will be the last ... ... since the code base will relocate to GitHub instead (which doesn't use revision numbers). What do these words mean? DoC has used version control software for a long time to allow me to manage my changes remotely between different devices, and to allow players access to the current development version. Until now, SVN has been the underlying software behing this mechanism to the point where the name was basically synonymous with version control itself. SVN was pretty much the state of the art when DoC adopted it, but by now Git has largely replaced it. Git has several advantages over SVN, which I will explain later as far as they apply here. How does that affect how I can access the development version? First of all, the repository has moved to a new online location: https://github.com/dguenms/Dawn-of-Civilization Unfortunately, to access this repository you will also need a new windows client. TortoiseSVN, the recommended tool for accessing the SVN repo can technically access Git repos, but the resulting folder will not have the format required by BtS to actually run the mod (because TortoiseSVN can only check out all existing branches of the repository at the same time, creating multiple subfolders in the local repository). Fortunately, there is the Git counterpart TortoiseGit. To install it on Windows, you first need to install Git itself using Git for Windows. Next, install TortoiseGit. Both installations will prompt with numerous settings. The defaults here are intended for unexperienced units and will have minimal impact on your system, so I recommend not to make any changes and accept them as they are. Git uses different verbs to describe actions than SVN. While they are not completely equivalent "under the hood", for the player it is sufficient to know that: * svn checkout = git clone (creates a new local repository by downloading from the remote URL) * svn commit = git push (what I do to upload my changes to the remote repo) * svn update = git pull (what you do to get my latest updates) Besides the new verbs, everything works like before. To create a new local repo for the first time, right click in the Mods folder, select "git clone" and paste in the above URL where required. A new folder with the name "Dawn-of-Civilization" will be created, which you need to rename to "RFC Dawn of Civilization" as usual. To get new updates, you can right click the RFC Dawn of Civilization folder and select "git pull". This command is not in the top level of the context menu by default in TortoiseGit, this place is taken up instead by "Git Sync...". This command has a lot of extra functionality that you don't need, and to avoid mistakes and extra clicks I would recomment to use pull directly. You can move "git pull" into the top level of the context menu in the settings -> context menu configuration. This only sounds like a lot because I like to hear myself talk. TLDR: checkout becomes clone, update becomes pull, don't worry about the rest. Why the change? As I mentioned above, Git is the standard in software development right now. In fact, DoC was the only project I was still using SVN for. Here are a couple of advantages I get from using Git: 1. Integration on github.com: Git and github are very closely integrated, with the website providing a lot of functionality to manage the repo. Assembla has improved over time, but github is still better by far. I think this is also a benefit for players, just follow the link and take a look. 2. Additional github features: Github also offers additional features that might be useful for the mod, for instance: * wiki pages * option to download the current repository state as an archive * code and history browsing * ways to collaborate and contribute, more on that later 3. Branches I've already mentioned branches, which basically means different states of the repository that can exist in parallel. The main branch I'm working on is called "develop" by convention. This feature allows me to work on multiple features at the same time without them getting in the way of each other. It also allows me to work on bugfixes when I'm in the middle of a larger feature, so no longer will I be able to use the "will look at it when I can revert my working copy" excuse. 4. Two-step commit process In SVN, I could either commit my changes to the remote repo or keep them local. With larger features, this is messy and potentially dangerous (what if changes are accidentally deleted). On the other hand, commits require complete and crash/bug free features as well as an internet connection, which I don't always have. In Git, I can make commits but an extra push command is required to release the changes to the remote repo and the rest of the world. 5. Additional repos While this also would have been possible on assembla, github makes it a lot easier to create repos for the additional modules (VD, soundtracks ...). Unlike the main mod, these repos also don't require recompiling the art into FPKs, so downloading the repo always provides an up to date version of these modules. 6. Labeled commits Github supports a tagging features which would allow me to label commits that break savegame compability, or comprise a new release. If we can download an archive on the website, why install the Git client? You'd have to redownload the entire archive for every change I make. The client only downloads changed files as you are used to from Git. Why now? Around release is the best time to make that kind of change, which I had already planned for a while. How does Git allow the community to contribute? Git has another feature called fork. If you have a github account, you can use it to create a copy of the current state of the remote repository that you have complete control over. This should make it a lot easier to develop modmods that are based on DoC. You can always do a pull from the main mod into your mod to bring it up to date with the main mod. This feature can also be used to help working on or suggest changes to the main mod itself, that goes beyond just making suggestions or posting files on the forum. For instance, if you see an error in the city name manager, instead of only reporting it to me (which might leave the problem at the bottom of my priority list for a long while), you can fix this in your own fork and then create a pull request for the main mod. This basically means that I receive a notification about the changes you have made, and only need to press a button to integrate them into the mod. I could see that feature to be very useful to help people contribute in areas like city names, dynamic civ names, text corrections or the civilopedia. If anyone is interested, I will follow up with an explanation on how to do this. Github also has an issues option. You can use it to report bugs there, which should be more organized than using the bug reports thread only (although I would appreciate reports there as well to be able to ask for a save and the like). Any further questions? The main info thread will soon be updated.