At one point or another, you'll have likely heard of this voodoo called SVN. SVN is something that allows group collaboration to happen in a structured atmosphere, creating a union between different versions of code, and an overall easy way for developers to work on different parts of a project, and gracefully merge them together without having to go through the trouble of having one guy sit alone in his home office for 8 hours reading over every line of code looking for conflicts. Don't worry, even if you're going at a project alone, SVN can be very useful to you for backing up your data, so read ahead.

What I'm here to explain however isn't how SVN works as a whole, but rather how the branch/tags/trunk structure works, and how you can utilize it to make sure you always have good working copies of your code readily available. What you don't want to find is that you've completely muddled up your code, and you can't figure out how to backtrack to the last working copy you had. That's where SVN comes in.

We're going to start of first with the branch. You can think of this like your workshop. This is where you'll want to start leaving your project between times you're working on it for simple backup purposes, and to show other developers what you are working on. You'll be working mostly from in here, so you'll likely have a couple folders and a bunch of random scraps of coding. This is normal. Once you get to a point where you compile your code, you run it, it seems to work okay, everything checks out. Maybe not all of the features work yet, but it is functioning without any errors at compile or run time. Time to move onto the next step. Tag it, and bag it.

Now that you have a working copy of your program, you're going to want to stamp it as a working version for future reference, a way for you to say that you've got a working copy, and if everything quite literally hits the fan, you can jump back to this version and know that you're starting on solid footing. Here is where you're going to want to commit what you have to the tags as a version number, like ProjectName v0.01 so you have some kind of incentive to what it is, as well as the repository(SVN) will order them by the number.

Once you've completed that step, you're going to want to commit it once again into the trunk. The trunk is your most recent working copy of the program. While you may have many tags of the program working for different versions, the trunk will always contain the most recent up to date working copy. Giving a new developer a good starting point to jump into the project, as they'll have the most recent copy to start from.

In short, to sum up what the previous paragraphs have just said, The most common SVN structure is the branch, tags, and trunk method. Branches are where your in development code is for the project. Tags are where version numbers of your working copies of the program go, and the trunk is where your most recent copy of the program in a working state goes. You can always download the trunk for the most recent working copy, or grab an older working version from the tags.

Using this method should greatly help you to keep your project managed, and greatly prevent you from losing your project, or ending up with an unrepairable copy. As well as making a group project a lot easier to maintain, from the prevention of one members code overwriting another.

I hope this helps you, and perhaps steers you towards using SVN in the future. I started using it, and have loved it ever since. Thanks for reading.
On the topic of version control I'd like to throw a mention to Git. A comparison is available here (and elsewhere online, of course), but what may be appealing to many BYONDers is that git does not require a server.
I believe Unknown Person intends to write a basic introduction to Git to post here. I'm not too sure what he'll cover that's BYOND specific, if anything, but an introduction is welcome all the same.
My link for "Git" was not to the Git project itself but to a freaking excellent introduction to Git. I've always been an SVN user, but that tutorial converted me.
You should have mentioned google code, yo.
Also, does anyone use mercurial, bazaar, or cvs anymore?
We use CVS at work. Which I find inexcusable. Mercurial has thus far appeared to be a poor man's git to me.
Great article, though I was also curious why the posts here have been focused on SVN over Git.

DivineTraveller wrote:
Also, does anyone use mercurial, bazaar, or cvs anymore?

I think mercurial is popular in the Python community.
I believe Stephen had an article earlier that was a general introduction to version control and it mentioned both google code as well as tortoise SVN. I likely should have linked to that article as a "read this first".
We use SVN at my work and it's pretty slick. I haven't really dug into how it works but it compiles our managed projects and runs all our unit tests with each revision. That's awesome. At the end of the night, it kicks off one last build and if it succeeds, it kicks off our testing processes. At which point, we install the build, run tests, and then deploy the build if our BVT's pass.

In the one attempt I made at trying to use SVN at home, I found it to be pretty heavy and overly complex so I bagged it.

I really like this topic though. I'll check out Git. In the mean time, I've been lightly considering DropBox for sharing BYOND projects. You can make an edit in place and people on the other side get notified of the change and can simply run the .dmb in place (just a few seconds later) to see the change. Obviously, it's less about source control and more about ease of collaboration and sharing.

Does anyone know if it's possible to somehow compile and validate BYOND projects with SVN or Git?

SVN doesn't in itself do those things, SVN commit hooks do them. I did used to have a DreamMaker [DME] compile hook on SVN for OpenSS13, so that a commit would fail if the resulting source code didn't compile.

Commit hooks is probably a topic worthy of it's own post, so I'll work on one for that basic scenario listed above.