SCM choice for a new user? [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. Closed 10 years ago.

Real easy one here guys. Best justification gets the win.

I'm a computer science student at a school you've heard of, and have been programming for several years now (about 8), so I've written a fair few lines of code. But since I've never really been distributing - source or binaries - nor doing team developing (though I'm sure I will!), I've never needed to learn source code management systems. I have a tremendously boring hierarchy of folders along the lines of src/project_name or src/class_code/hw_or_project_name and if I need to send the code to a friend or for grading, it's just a tarball away.

A few things have changed in recent years, as my projects have gotten bigger. My Mac, with Time Machine, now does hourly backups - this has saved me a fair few times, most recently when I made major changes over SSH... then saved and closed the stale copy in my editor a few hours later.

But, out of a sort of professional interest - along with an overwhelming sense that it could be useful - I've decided to learn SCMS. Now, I have plenty of experience as a source code 开发者_StackOverflow中文版'consumer' - git clone, svn checkout, cvs co, that sort of thing - but none as a maintainer, committer, or updater.

My question to you is: what should I learn? Now, a bunch of you are screaming "why one? you'll use many!" but I'd like to learn the basics of SCM, and get in the habits of actually using it, on the most straightforward system. There are a number of concepts I'd do well to internalize - branches, tags, merging, collaboration, etc - before I really need them.

To be clear, I'm no Linus Torvalds. I will be mantaining one, or perhaps a few branches. On my dozens of files, I don't mind if some operations take a few hundred ms more on one system than on others.

Now what do I have? I do have a webhost. They offer Subversion hosting a click away, or I could store other repositories there no problem. For reasons I can't explain, I'm rather partial to Subversion. But that's exactly why I'm reluctant to just jump in. I know Mercurial, Git, and so forth are the hot new things, being distributed, but I'm not sure why this is a benefit. In fact, I'm not quite sure how it could work.

So, what should I start with? Subversion or Git? Mercurial or CVS? Visual Source Safe or Perforce? (that last pair was a joke) And why one over the other?

Thanks for your time, and if this in the wrong section I apologize.

EDIT Thanks all! I appreciate your comments. Given the choice between Git and Hg, I'd probably go with Git - any disagreement? Second, why not Subversion? It seems to be the consensus (not just here) that it's old or otherwise obsolete. Why's that?

EDIT 2 So after reading all the responses and doing some more reading, I've decided to go with Git. "Answer" goes to the best justification, as stated above. Git seems to be more popular than Mercurial, even if it is a bit less clean. I'm pushing changes to my webserver, where I have viewgit installed, and it's working great. The impetus for storing a copy on my webserver is that I'd like to be working from several of my machines, and I expect them to get out of sync. I also expect to have the several working copies out of sync with each other and my server, and I now understand that Subversion is pretty weak at that. There's a lot I'm still trying to work out, but I've got it set up now so that I can pull/clone from http and push over ssh (next step is to set up Gitosis). To a newbie looking to do what I'm doing - you'll find that your "push" commands will work the first time, but any "cloned" copies won't track the changes you make. Git considers this a safety feature... I only slightly understand why, but it has to do with merging. The trick is to use this post-update hook on the server to merge the newly-pushed copy into the server's working copy.

---

Given the choice between Git and Hg, I'd probably go with Git - any disagreement?

Warning, I'm a mercurial fanboy.

Git is not bad, but it has some quirks you have to know when you use it:

• You can push into a non-bare git repo, but this will screw up the working copy there (It moves the branch HEAD to the pushed revision, but does not update the working copy. When you are not aware of this push, the next commit will undo the changes which were pushed into the repo, mixed with the changes you just introduced.). In hg a push to a non-bare repo just add the new history to the repo, and you get a new head on your next commit, which you then can merge with the pushed head.
• You can't easily switch between a bare and a non-bare repo (you can make a hg repo bare with hg up -r null, and get a working copy with hg up [some-revision] from a bare one).
• When you check out an older revision by a tag, remote branch name or commit-hash you get a detached head (I really like the title of that question). This means commits there are on no branch, and can get removed by the garbage collector. In hg a commit on an old state create a permanently stored anonymous head (You get a warning on the commit).
• When you come from SVN you have to know that git revert and svn revert do completely different things.
• Git has all features enabled, also the ones which can cause data loss (rebase, reset). In hg these features are there, but must be enabled prior use.
• git tag makes local tags by default, when you want a globally visible tag you need git tag -a or git tag -s. On the opposite hg tag creates a global visible tag, local tags are created with hg tag -l.

Some things many don't like about mercurial:

• Branches are stored permanent in the project history, for git-like local branches bookmarks can be used
• There are no git-like remote tracking branches (although bookmarks can be shared, and recently there's been work on them to work more like git's branch labels)
• Creating a tag creates a new commit in the project history (technically git does it the same way, but is much better at hiding this commit)
• You have to enable features that modify history, or are experimental (hg comes pre-packed with many, ... but they are disabled by default). This is why many think that mercurial has less features than git.
• There is no git rebase -i equivalent packaged with mercurial, you have to get the third-party histedit extension yourself.

Second, why not Subversion? It seems to be the consensus (not just here) that it's old or otherwise obsolete. Why's that?

Svn has no clue what a branch or a tag is, it only know copies. Branches and tags are simulated by having the convention that a svn repo contains a trunk/, branches/ and tags/ folder, but for svn they are only folders.

Merging was a pain in svn, because older versions (prior svn 1.5) dit not track the merge history. Since svn1.5 subversion can track merge history, but I don't know if the merging part is better now.

Another thing is that in svn every file and folder has it's own version number. In git and hg there is one version for the entire directory structure. This means that in svn you can check out an old revision an one file, and svn will say that there are no local changes in your working copy. When you check out an old revision of one file in git or hg, both tools will say your working copy is dirty, because the tree is not equal to their stored tree. With subversion you can get a Frankenstein version of your sources, without even knowing it.

A minor nastiness in svn is that it places a .svn folder in every checked out folder (I heard rumors that they want to change this behavior in 1.7), where the clean reference files for the checked out ones live. This makes tools like grep -r foo not only list the real source files, but also files from these .svn folders.

Svn has an advantage when you have big or unrelated projects, since you can check out only subtrees of a repository, while in git and hg you can get only the whole tree at once. Also does svn support locking, which is an interesting feature if you have files which can't easily be merged.

Keyword substitution is also supported by svn, but I wouldn't call this a feature.

---

I'd pick mercurial.

1. The set of commands are limited so there's not a lot to remember.
2. http://www.hginit.com
3. Mercurial's hg serve command lets you setup a repo server for small operations in 5 seconds.
4. Cross platform
5. You can use it locally, without branches and be quite successful until you want to get deeper into the advanced stuff.

---

The Mercurial over subversion case is pretty convincingly made in the first section at http://hginit.com/

Git and Mercurial can each read and write one another's repos over the wire now, so it really comes down to whichever interface you prefer.

---

One thing's for sure, don't start with CVS.

---

I've been using Mercurial and enjoy it very much. You can get a free Bitbucket account and start storing your repos in the cloud. It's also being used on some codeplex projects if you ever have the desire/opportunity to work on an OSS project that's on codeplex.

The basic gist I have found/heard is Mercurial is a little easier to work with but not as powerful as Git. However, both are excellent choices.

There's a really good free video on tekpub for Mercurial and Codeplex. It takes you through all the basics.

As already mentioned the http://hginit.com link is another good resource. It's also made by the same team who made FogBugz & Kiln. Kiln is an integrated environment for Mercurial and FogBugz with extras like code review.

I was using SVN on my local box to store my personal work but no more. With Bitbucket & Mercurial I won't have to worry about my local box dying and making sure I had everything backed up....

Bottom line is you can't go wrong with either Hg or Git but I would go with Hg unless you needed some of the advanced features which sounds like you don't.

Learning SVN isn't necessarily bad as there are a lot of Organizations using it but I would really concentrate on Distributed VCS instead. They really are the future. :-)

---

Being a newbie myself , I've used git and found it remarkably easy to use and intuitive, while the others have been a bit too overwhelming.Coupled with GitHub it makes for a wonderful little tool for source control,sharing and backing up code.

---

The best open-source choice is GIT. Check Git documentation. you Would also find lots of tutos over internet (youtube, and some developers blogs). A must not do is (start using CVS or Subsversion). Well at least is my personal opinion.

---

Use git and github

---

Once upon a time, cvs almost completely replaced its competition and ruled the world of version control.

Then it was itself replaced by svn.

And now, svn is being replaced by git.

Git is more complex than svn, so there might still be reasons to pick svn for a new project.

But its days are numbered. Git, Mercurial, and some proprietary systems are clearly the future of the VCS world.

Both git and svn can be used in a cvs-like checkout/pull/commit mode, so the bottomless pit of complexity (it's a lifestyle) that is git won't affect you unless you jump in the deep end.