I've been working for a few years, and one of the most interesting things I've come to learn are source code control systems. It is in fact something that at least in Spain all universities seem to lack, being so critical, so basic for the daily work, whenever is professional or personal.
When studying, the Source Code Control (from now on SCC) system used is either email-based (you keep versions of the source code in emails sent to your assignment partners), usb-based (the equivalent of a nighty build, as you will usually override previous versions) or if you spend enough time together, shared-folder-based (technique recently explained to my by a student friend).
If you're lucky, you will land into a job that uses some more advanced SCCs, probably those software-based.
Tip before continuing: If not, consider searching for a new job. If your employer doesn't values the sources as valuable assets, chances are won't either value you as a human asset.
In my case, I started using Microsoft Visual Sourcesafe. The dreaded VSS, hated by almost everyone who used it due a combination of ease of repository corruption, single-lock editing only mechanism, and other miscellanous problems. But it was also so simple to use that almost everybody could setup it, it was nicely integrated in Visual Studio, and well, it was mandatory so...
VSS allows many people accessing the latest uploaded file, but only one user at once editing it. In big groups and/or small projects this leaded to terribly waiting semaphores, and apart from that you just could do tagging and branching. But it was a first step.
Around 2006 I had the punishment of having to use CVS for around one month, and scratched the surface of Subversion for some months, but with the single-edit lock mode so it behave mostly like a better Visual SourceSafe.
But in general, apart from some personal experiments when Team Foundation Server was initially launched, I sticked to VSS until early 2009.
In 2009 I moved to Tuenti, and discovered the full potential of Subversion. From doing at most different desktop versions and small branching, I entered a sea of branching, merging, diff-ing and solving the feared merge conflicts.
At first was hard not to think in the concept of branches (as the name implies is just a copy of the "base branch" with modifications) but to fight with the new concept of conflicts. Multiple people editing the same files and someone with "the brown" of checking three versions of the same file and choosing the correct one.
But with time, you get used to it. I started having sometimes two or three simultaneous branches, and I can now merge and branch as if I knew from all my life.
And when we were "happy" complaninig about Subversion's crappy merges, we decided to switch to Mercurial. Mercurial is like the next step in evolution, as instead of fully modified files, it handled line-level changesets.
The Mercurial gurus promised no more conflicts, no more merge problems, all gone with this magic. Well, the reality is that, while working better than Subversion, magic doesn't exists and Mercurial still screws up some merges.
But in general, it is true that after a (hard) adaptation time, Mercural works better. The concept of having a repote repository + your local repository copy + branches allows an incredible degree of flexibility.
I can work on many projects at once, commiting to my local repo and changing branches without problems, and then push my changesets to the remote server.
I can now merge one branch from my repository directly in the integration or release repositories in a few seconds. I can even grab data from a colleage's repo, add my stuff, and then send both changes to a third one.
It looks complex but once used to it, using my Subversion at home feels limited.
We humans fear change a lot, but we should embrace it more often. I have complained about Mercurial sometimes, but I have to recognice I is very helpful.
Using an SCC is vital, and the earlier you learn to use it, the better. Even if it's a bad one, start with it and time will make you change and evolve.