I'm curious to what extent these version control systems apply to very new developers/programmers, like me. I'm in the very early stages of my 3rd game project (a space invaders clone) and I've decided to plan and control my process a bit more than I did in the first 2 projects. I have a list of modules I'll need, I pick a set to put into the next revision, and then copy the last revision and give it a new rev number. All of the coding is done from the same location, a flash drive I carry with me.

On the one hand, version control software is clearly widely used, so getting a good handle on it would be wise. This thread demonstrates that, as does browsing jobs on craigslist. Folks there often request links to work you've done, or a link to your git. So, when the time comes to look for programming jobs in a couple of years, it would be good to be able to show that I'm familiar with version control.

On the other hand, there's quite a lot of other stuff that beginners also need to be learning. If we try to add everything we need to learn in at once we'll get way too bogged down with getting a handle on new interfaces to ever learn and code anything. Also, when I research version control most of the features they talk about are designed to make things work better for projects with multiple people modifying the code base.

Do these version control software set-ups offer more for projects with a single programmer that would make them more useful for a beginner to learn sooner rather than later? As it stands I plan to see how my simple revision rolling method works for this project, and then hopefully move into one of the more formalized version control programs for the next project, which will be my first somewhat original game. If SVN or git or one of the others simplify more of the process, though, it would be worthwhile to go ahead and learn it now. Do the features available for solo programmers justify the learning curve needed?

Do these version control software set-ups offer more for projects with a single programmer that would make them more useful for a beginner to learn sooner rather than later?

I would say yes. You don't have to become a version control ninja (just the basics should be good enough at first), but simply checking in your code as you develop will allow you to rewind if you totally f*** things up and need to undo a series of changes you made because you realize it's just not working this way. Beginners do that a lot

Hehe, good point. I wouldn't necessarily need to master the whole thing, just get a handle on the basic stuff. And I can attest that being able to rewind would be nice, because I f*** things up plenty.

[quote name='shadowomf' timestamp='1358804132' post='5024044']
Could you elaborate what features you do require that subversion doesn't support?



One more question, do you use some explorer integration? I haven't found one that is comparable with TortoiseSVN which was always a bit of a show stopper. Maybe you can recommend one (for Windows).
[/quote]

I'm using TortoiseHG which is very easy to install and use, though I have the habit of often just typing in the commands in the commandline because they are so easy. SVN always needs to connect to the server, you just have the last version locally. For SVN I just have a command line tool installed and only use it when I need to.

With a DVCS you always have a copy of the whole history on your computer, can easily make as many repositories as you like so you are less likely to need to cram everything into one huge repository, clone them very fast for experimenting, commit or revert or update to any version locally even without internet connection and only push to the server when you are sure its ready, easily push on your USB-stick or really anything for backup or taking it with you.

No, svn commits are not atomic. I can commit a set of changes to git/hg/bzr/darcs as one single atomic operation, and then uncommit/revert in one single atomic operation, or cherry-pick and apply in one single atomic operation. If I'm using svn and commit a changeset of say 20 files, then I get 20 single commit operations.

I don't get you. If you commit 20 files, Subversion first looks whether any of the 20 files was committed by anyone else in the mean time. If that's not the case, the commit will succeed, atomically, for all 20 files.

If any single file has been touched by anyone else in the mean time, the commit fails with "out of date, please update". A properly configured client will run the update automatically, too. Now changes are merged automatically to your working copy, if possible, or you are prompted to resolve conflicts. After resolving conflicts, you commit a second time. And, again, this will succeed (for all 20 files) or fail.

Of course you can commit 20 files one-by-one. No, that won't be atomic, what a surprise. But it won't be atomic in any other revision control software, either.

Same is true for branching. Yes, branching is (logically, not technically) a copy of a complete directory, so what? It has no bearing, there is no such thing as a half-copy. Branching "copies" all data to a new directory, but in reality it only creates a virtual directory referencing the files of the current revision. Concurrent commits to trunk (or to whatever) add new versions (with a higher revision number) to the original directory, which has absolutely no bearing for the copy.

Besides, this is the exact same way Git works internally. Torvalds only called things "tree object" and "blob object" rather than "file" and "directory", but they're still the exact same things working in the same way.

If you have a toy project or a small hobby project that's never going to get released, this may not be a consideration for you.

One of the toy projects that's never going to released and that I'm involved with had 40k downloads last week. It has slightly over 7400 files (including some non-source files) with 1.1 million lines of text/code. Doing a complete, pristine checkout takes 1m35s (tried just now). Too slow for you? OK, fair enough.

But that isn't the fault of Subversion, it's reality. This project's repo is served via WebDAV/SSL (which is pretty much Subversion's slowest possible mode of operation) on a MuchoCheapo-class server located on a different continent. Downloading lots of stuff over the internet takes time. So what, nothing surprising there. Git can't do the job any faster or better (and if someone says it does, he's either comparing apples and oranges, or just lying).

Checking out a slightly smaller (about 15%) toy project that I'm involved with, from the above mentioned server on the LAN takes 16-17 seconds. Again, not surprising, because that's close to the peak bandwidth that the NAS delivers. Downloading a .tar file of comparable size is maybe a second or two faster, not more.

Branching either of these toy projects takes about 1-2 seconds, plus the time to check out the new branch (though that time is close to zero, if you switch rather than checking out anew). So, what exactly are you trying to tell me? Your harddisk is faster than the internet? Wow, I'm shocked.

You really have to compare apples and apples, not apples and oranges. Is "branching" very fast with Git? Of course, but only because you are not branching when you're telling that you are. The act of branching involves making a copy and communicating changes to others. Half of that process is "forgotten" in the comparison.

Now of course, merging is another story. Merging usually takes days, literally. However, that's just what happens when people edit both branches without discipline. There are conflicts, and conflicts must be merged or resolved. When they cannot be merged automatically, a human has to do them by hand. That's just what it is, nothing surprising again, and Git can't do "magic" in that case either.

On the other hand, we have for example images tagged with [font=courier new']svn:needs-lock[/font], which is a form of "magic" that Subversion will trivially do for you, and that Git can't do at all.

To avoid a misunderstanding: Again, I'm not saying that Git is an inferior revision control system. I'm not opposing to Git as such. If you want to use it (either because of political reasons, or because you have a very special need and it really does just what you need), that's fine with me.

I'm only opposing to the Torvalds-style "Git is God's Gift to Humanity, everything else is shit" propaganda. Everything else is not shit.

Every system has its advantages and disadvantages, but they all have their legitimate place, and they all (well, almost all... my experience with RCS was truly traumatizing) work reasonably well for most people.

Are the latest files in Mercurial's local repositories saved in their original file format or a special format / archive? What about SVN? What about git?

If I wanted to manually modify the up-to-date repository without invoking any version control tool or command, which ones permit me to do so?

I've installed multiple different source control tools before (and apparently still have TortoiseSVN and TortoiseCVS installed), but they puked over my projects' neatly organized folders with special files and junk, so I always returned to ye ol' manual zipping up the entire directory and renaming it to the current date, then TeraCopying it to other networked machines for safety. I really want, and recognize the need, to learn at least one of the major source control systems, but haven't had the time to learn and customize them to keep my project mine and not theirs.

As an analogy, I also don't like iTunes and Windows Media, for how they take over and 'organize' your music files for you - and spend alot of time crawling my computer looking for new files without being prompted to. So I organize my own music files in their folders how I choose, and I use a media player that works with me instead of takes control away from me. (I use foobar2000, if anyone was wondering)

What source control system works best with a lazy finicky micro-managing NIH nitpicking solo-programmer who-wants-files-local-and-unobfuscated like myself?