Can someone explain source (versioning) control to me? [closed]

Question

I've never worked on a professional project with a team, as I'm still in high school. As a consequence, I've never been exposed to this whole "versioning" and "source control" thing. Are they the same? How exactly does a program that manages code manage code? I've heard you have to check out code (copy the existing code?) and merge it back in (what happens if someone changes code that you didn't change and you change something else and merge it in? Surely, his code is not replaced by your older version.) And, finally, what is the best/easiest example of this type of software?

Answer 1

I've heard you have to check out code (copy the existing code?) and merge it back in (what happens if someone changes code that you didn't change and you change something else and merge it in? Surely, his code is not replaced by your older version.)

That is precisely the reason for version control. It wouldn't really be a very useful tool if all it did was blindly overwrite people's code, would it? ;)

Source control tools maintain a repository with the entire history of the codebase. Every change is checked in as a delta, saving just what has changed. That means that if you and I both check out version A, and I then edit file B, and you edit file C, and we both check in, the source control software will compare the differences and where no conflicts exist (as in this case), just apply both changes, and if conflicts occur (if we both changed the same lines of code), it rejects the attempted check-in and tells you which two versions of the file had conflicting changes, and asks you to merge them manually. (usually it is also able to highlight the changes so you can see visually what has been changed in each version). So it never overwrites changes.

Other tasks it'll do for you is:

• Tag specific versions or milestones so you can easily find them again later (this is the version where we finally fixed annoying bug #2524, this is beta 1, and so on
• Branch the repository into two, allowing changes that may go "out of sync" temporarliy, or even stay separate products forever (think of PHP simultaneously maintaining their PHP4 branch, while also working on PHP5. At some point they simly branched their codebase so while they started out identical, they can now apply patches to one without affecting the other). Of course it can also attempt to merge these branches back together (you may create a branch for each major feature in your product, perhaps, so they can be developed in isolation without being affected by the gradual changes happening to the rest of the code, and then when the feature is done, merge its branch back into the main repository)

There are two basic kinds of source control tools, the centralized ones and the distributed ones. Distributed are the big new thing, while centralized has been with us for decades. In brief, centralized version control simply means that there is one master repository server, where all branches and the change history for each are stored. This server is responsible for merging checkins and all that. So every time a developer checks code out or commits it to the repository, this is the server he syncs up against. Distributed ones simply ditch the "main server" aspect of this. Instead, every time you check out your code, you create a new repository locally on your own machine, at the path you check out the code to. Then you can work against this local repository, which does all the same things, tracking change history, merging changes and so on, and once you're ready, you can merge your repository into, well, any other repository. Typically, you'll probably want to merge it into some kind of "main" repo where all the code gets glued together, but you can also merge it into your codeveloper's local repo, if perhaps he needs that feature you've been working on, but it's not yet stable enough to go into the main repo. So it gives you a lot more flexibility, and allows you to maintain a change history of your local work, without risking breaking the build at the master repository (in a centralized setup, what happens if you check in something that doesn't compile? The entire team is screwed until it's fixed. And if you don't check it in, you lose the benefits of version control, preventing you from reverting to a previous version if you find out you've been introducing new bugs)

And, finally, what is the best/easiest example of this type of software?

Hm, the most popular is easily SVN, which an old-fashioned centralized system, but it's a bit of a pain to set up imo. Requires special software on the server. I personally am quite fond of Bazaar, which is distributed, and a server repository only requires FTP access and nothing else on the server.