Version Control, You, and why You need Version Control

News & General Discussion
1

Lately, I’ve seen - and heard - a number of my fellow indie developers who assert that they just don’t need version control for their projects, for a variety of reasons.

This of course is completely false. Yet merely explaining why this is false would do nothing to help said indies understand why I assert this view of version control is incorrect, because in speaking with and reading posts from these developers, it appears there are a number of misconceptions surrounding version control in this community.

The objective of this post is threefold:

  • To remove the misconceptions about version control.
  • To explain why version controlling your project is beneficial and preferable to some shoehorned archival process, and
  • Finally, to give some information about free/inexpensive ways to implement a version control system for your project.

Misconceptions of Version Control
Misconception: “A control system will not help me archive my project. Dropbox works just fine.”
Reality: False! Dropbox provides a shared space for storage and collaboration, yes. What Dropbox lacks is the ability to create branches, revert to previous changesets, log work, or document comments about a changeset - all useful things whether working solo or in a team.

The people who advance this argument are typically graphic artists, though some programmers have also advanced the fallacy. Often, the reason cited is complexity: “a version control system is overly complex compared to simply putting a file in a folder.” This is false; in most version control systems, it’s easier - you keep the change where you left it, right click the folder, and select an option to perform a commit to the repository in question, and write a small comment about what you did, for posterity!

Even if a practitioner of a different discipline has a different setup - for instance, an artist commits a UV texture from their sole commit folder, and a programmer pulls it down into a full asset structure - it matters not! The artist sees what they need to. The programmer sees what they need to.

Misconception: “Version control systems are only for programmers.”
Reality: False! Version control systems exist not only to store assets and information about the things that changed, they exist to provide a backup point. What if Joe the Artist’s best friend comes over to his house, downloads some malicious software that erases Joe’s hard disk? Not much of a problem if Joe has committed his work to a remote repository; he would have to re-setup his computer, and checkout his little branch of the project.

Joe the Artist has been saved by an archival system intended to support an entire team, not merely a programmer’s tool. I would like to add, at this point, that just because a programmer uses something does not mean that it’s simply not a tool for artists as well.

EDIT (@imaginaryhuman’s concerns) - Modern version control systems have a generally user-friendly front end (TortoiseGit and TortoiseSVN are two such front ends I have direct experience with) that insulates the user from really technical stuff and lets you easily perform the basic tasks (commit, checkout, etc.) It’s incredibly easy, many consider it intuitive, and the installers typically don’t ask you difficult/technical questions. You do not have to be a programmer to use these well enough to do your job.

Misconception: “Version control systems are difficult.”
Reality: If you’re a project manager charged with keeping track of various branches - kind of like what a AAA studio would encounter - then, perhaps. For us indies, with our limited scopes, this is not usually the case at all! In fact, shell extensions like TortoiseSVN, and TortoiseGIT (both favorites of mine, for their easy shell integration and cost of $FREE USD) have been or are constantly being refined to be more user-friendly as they progress!

Speaking as a version control user, I prefer Git for various reasons, but using Git via TortoiseGIT is probably one of the easier ways to start using version control. The fact that free remote hosting options, like GitHub, exist only helps ease the barriers to entry. BitBucket also has an excellent, and private, free package as well!

Is Git perfect? No, but I can nitpick any bit of infrastructure. However, it gives you the crucial archival abilities defined above, most notably the ability to recover from catastrophic conditions with a minimum of pain. I don’t care how much you love DropBox, it can’t do all that for you. Sorry.

Misconception: “Version control takes control away from me.”
Reality: Completely False! Version control gives you freedom to experiment more readily, because you can move between existing commits, or salvage file state from an earlier commit. If you’ve been working on a super-duper awesome 256x256 sprite, but you decide that the one you made a week ago looks better? Just, go back to that commit, and use last week’s version instead.

Some of this may come from the name, which honestly, I have a problem with. It should something along the lines of, “Project Snapshot System”, I feel, because that’s what modern version control systems are. All you’re doing when you commit is taking a snapshot of some file substructure, and pushing it somewhere else for safekeeping. For those who have been led to believe that version control is some robot that controls what puts out versions of your software? It’s not, that’s your job! All version control does is keep track of the snapshots for you.

So, why is Version Control good?
To reiterate - version control is far more than a structured way of storing your project.

Version control allows you store your project, possibly remotely, stores sets of file changes with records of when they occured, and usually some forms of comments about said changes. This allows your project to be robustly stored in the event of some catastrophic circumstances that would cause partial or complete loss of project.

Version control allows you to create branches, for those hopefully rare times you are forced to work on something in parallel with someone else. For that matter, when collisions occur, version control provides tools to resolve these collisions. This is particularly important in teams, as sooner or later two people will touch the same file, in contradictory ways. If you could not resolve collisions, it would lead to re-do work, which can be significantly expensive to your project.

Finally, modern version control systems provide refined GUI/OS-shell integrated interfaces for performing operations on the repository. Often, it is possible to stage a commit with two clicks on a folder, and some small amount of typing for the comment about your commit. Updating your repository is often even more trivial than that, usually a right click and a left click (and some waiting for the small file download from the repository.)

If you don’t believe these are useful, please see the misconceptions section above. Most of the reasons I’ve encountered from my fellow developers are addressed up there.

Ok, sounds good. I bet getting set up is tough, right?
Version Control Tutorials By Asvarduil

With Subversion, one of the slightly older systems out there, it can require a little bit of thought (you can read for yourself a few ways here. It used to be worse, when I was in college, but fortunately some better packages like VisualSVN have been introduced.)

Fortunately, I would like to expound upon the ease of getting started with TortoiseGIT. You don’t need specialized server and client software; it’s all inclusive, because every end user is a copy of the database, making it extra robust against catastrophic data-loss. What’s more TortoiseGIT makes performing standard operations a breeze.

Conclusion
If you are using DropBox as your archiving option, and you have read to this point, and you see the merits I am speaking of, do yourself a favor and stop using a file sharing site for version control. It is not. I have provided two sets of simple options that can be implemented in about as much time as it takes you to make a couple of sandwiches, that are user-friendly, efficient for managing, and will protect you from getting smacked full-on in the face by Murphy’s Law (for the most part.)

I hope this ‘short’ post has helped you to better understand the options that are out there for archiving your project, why they aren’t just for one discipline or another, and how to efficiently implement them in your own project.

Final thought - DropBox is for file-sharing. I recommend using it for just that. It is not a file control system!

7 Likes
2

+1

3

I put off installing a version control server at home for ages because I thought it would be annoying to setup and i was going to be dealing with apache bs…

I was wrong. VisualSVN was so easy to setup its ridiculous.

svn + tortoise ftw

<3

If youre having code problems I feel bad for ya son, I got 99 problems, version control aint one.

3 Likes
4

+100, and I requested a sticky on that post.

5

Thank you all. I simply could not take hearing the same stale arguments over and over again, and then seeing our newcomers parroting the same incorrect beliefs.

In addition to helping people prevent catastrophic data loss from preventing their project from taking off, version control provides nice ways to help manage a project’s growth. Theoretically, this should contribute to a slight boost in the quality of the projects we see as well. I know it has helped me greatly with mine - being able to just say, “nah, never mind, go back three commits, I’m starting this feature over” is a huge help.

1 Like
6

Oh, it gives a massive boost in quality. I remember in my own early days switching from non-version-controlled projects to version controlled ones. There were growing pains, but the advantages immediately outstripped them.

For starters, we no longer had to spend 30+ minutes each day manually integrating each other’s work and then re-distributing the baseline for the next day. If you do the math, in a 2 programmer team working 8 hour days that’s over 5% of our time spent doing something that can be 99% automated to take less than a minute in most cases. Manual merges are also significantly more error prone.

Secondly, implicit backup. We didn’t even have to think about it. Check in when we’ve finished something and bam, already backed up.

Thirdly, when it’s remote, you can access the project anywhere you have a computer with internet access. Any member of your dev team can do this, including dev teams who are physically nowhere near you. (As a bonus, you’ve then got off-site and/or distributed backup, potentially in multiples.)

Fourth, have cleaner code while being way more adventurous with it. Want to cut out a whole subsystem and rewrite it from scratch? Bugger commenting it out and keeping all the stubs, just delete that crap. Same goes with any code you make redundant. If a piece of code isn’t being run just delete it, right now. Why have it taking up room, brain space and potentially compiler time? Clean it out, and get it back from your version control if you need it later.

Fifth, branching. Want to prototype something or make a custom demo without it getting in the way of the main development? Or give a feature a go that you’re not really sure about? Easy. Make a branch, do whatever you want with it, retain all of the above advantages. If it works out you can merge the new branch into the main branch. If it doesn’t you’ve lost nothing other than the time you spent giving it a go.

Sixth, saving of HDD space. Before version control we sort of had our own version control where after our merge each day we copied the whole project to a backup file server. This took bucketloads of HDD space, as you can imagine - each day we were storing an extra entire uncomressed copy of the project. With any decent VCS you only add the delta each time, so often the project’s entire history (everything that every developer has ever done since day 1) takes up somewhere around 2x the project’s current size. This also means its way faster to access remotely.

Anyway, I could keep going, but if you’ve read to here and aren’t convinced, nothing I can say will sway you.

7

Speaking of version control, has anyone put a dent into Plastic SCM? Wondering as Unity now provides it built in, and the licensing of it is pretty indie friendly

8

I personally haven’t; until you brought it up I didn’t know it existed! I’ll look into that.

EDIT: @angrypenguin - Having looked into BitBucket, I added it to this post as well, so that people don’t leave their code hanging out.

9

Glad I could help. I’m a big fan of Atlassian (the new owners of Bitbucket) since they’re awesome and local, but it’s worth mention that they’re not the only ones offering a kickass service in the area. They just happen to be the only ones I’ve used in years (because with a service like that I simply don’t feel the need to look elsewhere).

10

For me its still too programmery… if it’s a simple matter of running an installer that doesn’t ask technical questions and then Unity just works without without having to set up stuff like servers and addresses and folders and all that gubbins, then I’d do it, but it for me has a very geeky reputation that puts me off. Someone tell me its incredibly easy and intuitive and even a beginner could use it?

11

EDIT: Updated the original post with an answer to your concerns. Thank you for voicing them. Git is probably slightly less intuitive than SVN, but, well, I get into that a little more in detail below…

That’s why I recommended the TortoiseGit route. The installer does a pretty fair job of keeping the technical stuff to a minimum, and the shell extension keeps a lot of the inner workings insulated from you (unless you want to use them, in which case go for it). There are some hoops to jump through, as with every system (for instance, in Git, when you make a change you usually commit first, then push to a remote repository - as I said in the OP, every end user is a copy of the database.)

Before I wrote this post, I actually didn’t know about the VisualSVN package. I know from experience that the TortoiseSVN shell extension is probably the most direct and un-technical front-end, but was concerned about talking setting up the server part SVN, for the reasons you brought up (being too ‘programmery’ - I remember having to jump through a bunch of highly technical hoops that made my programmery head ache.) Fortunately, it seems some of those problems have been remedied by time and technology.

Since you’re concerned about too many knobs and gears being exposed, I would probably suggest to you the VisualSVN route. In the end, it’s up to you. But, I cannot stop crusading against this horrible fad of using Dropbox as a source control system - this broken belief isn’t actually doing any of its practitioners any favors. I implore you to stop using it, for your own sake.

An additional thought - if the front end for these systems are too programmery for you, being an artist who delights at refining the form of a thing into something more simple and beautiful, why do you not apply your talents of art, simplicity, and ‘just works’ to this space? Help the codemeisters behind these systems have a better, more simple front-end that dosen’t turn off even the most uninitiated artist? Surely that would benefit us all, especially us programmers (we don’t like having to sift through technical option after menu after dialogue, either, you know.)

12

It’s pretty daunting at first, but once you get the knack it’s super easy. There is of course fancy advanced stuff you can do, but you don’t need to. In a nutshell:

  • When you start something new, create a “repository” for it and put it in the repository. If you’re using a remote service that handles things nicely for you, all you need to know about the repository is its address, which is a URL just like any other web address.
  • When you add or change something you then “commit” it to the repository, possibly along with a “push”. This sends your changes to the repository.
  • When you want to pull down changes from the server you “check out” the changes, possibly along with a “pull”. This gets any changes that you haven’t already got from the server and applies them to your local copy.

Slightly advanced, you can essentially time-shift your local copy. Details are different depending on what you use, but basically it fast-forwards or rewinds the repository from a given point using the history data.

13

Really good summary why to use version control systems.

It’s really surprisingly that you still have to make advertising for such systems. Apparently everyone must make his own experiences with lost work because of a hard disk crash or something like this before they see the advantages. I’m working since years with SVN and GIT and I can’t live without them anymore :wink:

14

Here’s my view of it. If I’m going to work with a team online, then it is going to be a very small team team that is streamlined and feeding assets to me. I will keep the compiler and do the programming. I do not need version control as only I control the versions locally.

15

Ok, so you’ve decided that one of the features of version control is of no value to you. What about all the others? Infinite undo, an implicit backup solution, never lose a piece of code again, cleaner code, project portability… all useless to you?

Actually, on second thought, it doesn’t sound like you realise what is meant by version control. It is not controlling the versions of your project’s outputs or builds, or even controlling the versions of things inside it.

16

As much knowledge as I thought I had, I feel like a complete idiot when it comes to version control. I only have minimal experience in eclipse and visual studio. I read all your links and downloaded everything and set it up like they say, but then I am left blank as what I am supposed to do or how it works. Not sure if the versions currently out of the software are newer, with changes not in the tutorials. So essentially I got rid of everything and want to start from scratch. What do you recommend for someone who has no ideas about pretty much anything VC? I have dealt with the swift hand of losing a whole project about 3 years ago, and never want to experience this again, as I am now working on a much larger project. Perhaps an idiots guide? hah

A lot of these tutorials I researched and found seem to skip steps and leave the user open ended without any clear direction. They talk to you like you know this information already. Yet to find one that talks to you like you are brand new to this stuff.

17

Difficult ? Technical ?

No, it is pretty easy actually

Here is an example of the steps if you want to work with SVN :

  1. Google “svn hosting”, choose a provider and a pricing plan
  2. On the provider website, create a repository, setup a user and a password (easy)
  3. Download and install tortoise SVN. (straightforward)
  4. Right-click on your project folder, choose “SVN checkout …”
  5. Copy/paste the repository URL from the website, login with the user/password when prompted.
  6. You’re ready to go ! Right click on the folder and choose commit to commit your files / modifications.
18

First timers will typically have some files they already want in the repository though, and that doesn’t tell them how to do that.

In short, what you want to do is check out the empty repository into an empty folder. Then copy your project files into that folder and “commit” them back to the repository as your first change set.

19

+1 to all of this

An additional benefit with some repository hosts is being able to manage an Issues log development milestones, creating items for bugs, improvements etc and tie them into a particular milestone, and then being able to refer to them in commit messages.

In particular I use Github for the repository with straight-up Git software on my PC after a friend ‘forced’ me to learn it for a project (totally worth it), and with that simply using an issue number in the commit message will mean that on the Github website when reviewing a commit message it will link to the issue item directly e.g. just typing a commit message like “Changed method to use X to address issue #7”, the ‘#7’ will be a hyperlink to the item.
Might seem small but if a project gets large I bet it’d be super useful.

20

I can see how it is good for backups and I that is the strongest draw for me. I don’t know however, how it makes for cleaner code. Seems to me it would be more convoluted by using time travel. I guess I don’t understand version control.