I am going to try to answer to this point by point by expanding the excellent considerations from Eonwind, Eredin and Serneum. I tend to write too much and this is a thread with a broad topic so I apologize in advance for the wall of text .

1) In general, I agree with Eredin on this one. Git is great to implement the feature branch workflow, but given the size of the team and the fact that each developer works on a single feature, this wouldn't provide a great benefit right now. But it would make sense to switch to git if we decided to completely change platform and migrate the code to github (as suggested by redhound). Github has the advantage of making the "fork and pull request" workflow very easy which IMHO fits very well the current PS development process and adds few advantages:

• It's clean: instead of creating a lot of branches in the main repo, the prospect/anybody can create a copy of the repository in its own github account, and if he drops the task he doesn't leave dead branches anywhere.
• The pull request is basically a work-in-progress patch. Github creates an open discussion associated with each pull request and anybody is able to check the current changes in the code and suggests modifications to add to the pull requests on-the-fly. Once everything is ready, a member of the official team can merge the pull request into the main repo.
• The main repo remains clean. Each feature requires several commits, and (especially for complicated features) there can be commits that introduce bugs and break the build of the main repo. The pull request is merged only at the end, so this possibility is greatly reduced.
• The project would never miss a bit of a contribution. Working on its own online repo, a prospect can make as many commits as he wants instead of creating big monolitic patches. If he drops the task, those small contributions are not lost because github creates a local copy when a pull request is submitted, so they can be merged and picked up by someone else.

Moreover

• On github there is a fully-featured, easy-to-use issue tracker integrated with the repository.
• I don't have numbers, but I have been involved in several projects using svn and git, on sourceforge and github, and some developers tend to stay away from svn simply because they don't like it. Moreover, I have the feeling that the developers community is gradually moving to git and github in particular, so all the "kool kids" hang out there .

To sum up, I think moving to git not only would speed up and simplify the workflow, but also that it would be better suited to attract new developers (which is IMHO the killer advantage considering how much lack of "manpower" is slowing down PS ).

Ah, and as Serneum pointed out, moving an existing svn repo to git is very easy https://help.github.com/articles/importing-from-subversion/.

2) I agree with Eonwind on this one. There are many cases in which the same feature in order to be implemented touches multiple parts of the code: client, server and common libraries. Splitting them could make it difficult to track the changes in the history.

3) Everybody agrees on this one .

4) Unit testing is great and I loooove test-driven development  . This being said, doing decently comprehensive testing in complex videogames is generally tricky. All the existing PS code has beed tested for many years in-game, so I'm not so sure that all the hours needed to write all the unit tests at once are worth being spent this way. Not to mention that writing tests is crazy boring and it would be hard to keep a coder motivated on this project . Also, unit tests work best when they are written by the same person who writes the code tested.

IMHO the best way to gradually introduce test-driven development in PS would be to assign to somebody the project of setting up the unit testing framework with a simple example. Then it is simply a matter of changing how contributions are accepted. When someone writes a patch with a new feature to be reviewed, a dev can ask him to add few tests about it. When a bug is fixed, a test can be written to ensure that there won't be any regression with future contributions. This way also the critical existing part of PS code would gradually be tested.

As a final consideration, PS is in the process of porting to a different engine (and a different repo). I think this is a great opportunity to start pointing the project in this direction. Unreal Engine also has its own testing framework https://docs.unrealengine.com/latest/INT/Programming/Automation/TechnicalGuide/index.html

5) Eredin said it all .

I'm currently doing a big code refactoring of the music code, but once I'm done I could volunteer to help with github migration or with setting up the testing framework in the new repo in case you guys would be interested.

I've long thought that it would be nice to invest some resources in speeding up PS development, and since we're developing a game, why not using the principles of gamification to do it? I'll give the first example that comes to mind just to make it clear.

There could be an Architecture Faction. To become an architect a character might have to complete a quest that requires some study of the architectural styles of Yliakum. After that, one may be able to participate to the in-game contests announced by the Vigesimi (i.e. the development team) on the dashboard. The contest may ask for a new 3D object or a texture. The large part of the project can be organized out of the game (through the forum for example) if implementing it in-game is too much time-consuming, but the important thing is that winning the contest gives an in-game prize (experience, trias, faction points, ...). Increasing the level of architecture faction could give access to more difficult and rewarding contests. It is just a raw idea but you get the gist.

Maintaining a system like this will require some "manual" work from the dev team, but IMHO the effort needed to implement it would be very reasonable if we compare it to the benefits on the development process and on the joy of all future Yliakum architects :-) .

The main point is: how cool is gamification?