Code Submissions

[Augustus Lucifer]

While looking into ways to manage the AUH files, I've come across a number of problems. Every version control method out there doesn't completely and totally suit our needs, due to the nature of the project. But trying to move forward without a VCS will pretty much murder any chance of the mod seeing daylight, because it means heightened disorganization, lack of proper workflow, and limited number of contributors. There's three viable methods for getting builds out and work back in.

The 'Old' Way

The 'Old' way is what we've been doing lackadaisically. That is maintaining separate builds, where anyone who wants to make a change has to change it based on their most recent version of that file, and then a long period of time has to be spent reconciling the builds because their base files could be extremely different. These are distributed generally via file hosting sites, in the form of installers or archives.

Pros

- No tools needed. Since developers aren't interacting with an intermediary, technically they don't need any of the tools required by the other methods.
- Free. Distributing files on a file hosting site is a free way of distributing them.

Cons

- Inefficient. If more than a couple people are working at the same time, the amount of merging that will be needed can be phenomenal. Since I end up having to do all of this, and I'm already tasked with the brunt of the coding, scripting, and some management aspects, it's simply inefficient.
- Dangerous. When the latest version of the files is only present in one place at one time, it's in serious danger of being lost due to hardware failure.
- Slow. For every hour spent doing actual changes, it may take twice that to combine the changes, making updating to newly available builds tedious.
- Closed. As developments are only saved on the local computer until they can be included in a new build, developers aren't privy to updates, which makes it harder to collaborate on ideas.

SVN

SVN, or Subversion, is a Version Control System (VCS) which is centralized, and has been an industry standard for a number of years. It allows teams to develop collaboratively by committing to a central repository, where the changes can then be pulled back to the local computer.

Pros

- Efficient. Multiple people can be working on the same files, and the repository is equipped to handle most types of concurrent changes.
- Great Windows integration. Of all the VCS systems out right now, SVN has arguably the best Windows integration.
- Fast. Fetching from and pushing to the central repository is fairly quick. I believe it uses FTP, so speeds would be comparable for the transfer of files. Since it only grabs the files which have changed, not all files at once, it's incremental transfer.
- Safe. The files are located at the central repository at all times, and most repository hosting sites have redundancy RAID arrays as well as periodical backups to insure the data can't be lost.

Cons

- Not idiot proof. Since all changes and file histories are stored centrally, the common workflow is to always push changes. Since there isn't a 'waiting' area before the pushed changes overwrite the files in the repository, there's the potential for screw-up. However, all files have a central history which can be referenced.
- Competence required. There's tools that need to be used to work with SVN, and developers need to be able to follow instructions on how to structure their workflow so that they don't infringe on other members of the team.
- Branching difficult. Subversion wasn't made for branching; it has the features, but it wasn't made for it. Using branches feel more clunky with SVN.

Git

Git is a Distributed Version Control System (DVCS), which is part of the new wave of software collaboration trends. Open-source projects needed a way for development to be more workable when end users were not managed by a corporate assignment to a specific task. It has all of the features of SVN, but contains some significant improvements.

Pros

Cons

- Geeky. Git is on a level above not being idiot proof in some respects, since its client applications for Windows are just now coming into the light. The ideal array of Git operations are still run from command line, but there's a couple good GUIs which should suit our needs well enough. The way git works may also be harder to grasp, in terms of what makes it tick, but that's irrelevant if it does what we want.
- Binaries. From what I've read, Git is not good for working with binary files. Binary files are effectively any file that is non-text. If it can't use delta compression on it, then it will have to store the same file twice in order to keep up a history. This is a space consideration more than anything else.