I'm currently working on several projects on my own (at least the developing part is done only by me :). Using Eclipse with different Java, R, SQL and other source files I'm wondering what version control system would be best for me.

At the time the history of Eclipse IDE seems to be enough, but I'm not sure if this will be true in a month/year...

What solution would you recommend and why?

To be more precise: I'm quite sure to use SVN or git if I decide to use a full version control system. But I'm just not sure if it is necessary...

small update: has the release of Eclipse Helios added new opinions?
+5  A: 

Git, because you can start right away and don't need a central repository server.

Some other advantages (compared to other SCMs):

  • Less cluttered filesystem: Git only creates a folder at the root of the repository (unlike e.g. SVN).
  • Does not interfere that much with "normal" file handling functions. E.g. in SVN you need to use custom commands to rename or move files. That is not the case with Git.

I have the feeling Git is very lightweight, so there no reason to wait until your project is "big enough" or whatever.

Felix Kling
this may put the decision towards git
+1  A: 

As far as I understand, it is just a question of which version control system you prefer most.

But the most performant system is probably git I think. for the eclipse plugin :)

I would recommend to use a version control system anyway. Even in small projects you will come very fast to the point that a previous solution maybe would have been better. Without a version control system you will do hard reverting changes or revert to previous versions (well, that is one of the great advantages of these systems, right? ;) ).

+10  A: 

I'd recommend pretty much any of the distributed version control systems. I've used git and hg in anger, and poked at fossil (I include it because it offers some features that git and hg lack). I'll break down the major pros and cons in my eyes (NOTE: if they all have the same advantage I'm not going to mention it, e.g., they're all fast and lightweight):

  • git
    • Pros
      • Very flexible
      • GitHub
    • Cons
      • Steep learning curve
      • More flexible
      • Eclipse integration was lame the last time I looked
  • hg
    • Pros
      • (IMO) more consistent commands
      • Less flexible
      • BitBucket
    • Cons
      • Less flexible
      • Doesn't have quite as much momentum as git
    • Caveats
      • I haven't checked on Eclipse support lately; it used to be better than git's, but seemed rather stagnant
  • fossil (disclaimer: I haven't used this one in anger)
    • Pros
      • Written by the man behind SQLite, so you can be fairly sure it's SOLID code
      • Provides more than just version control, e.g., a distributed bug tracker
      • Easy to set up for others to access
    • Cons
      • Not nearly as much momentum as git or hg
      • I'm pretty sure Eclipse integration for fossil is non-existent (it was the last time I looked)
      • No free hosting that I know of to parallel GitHub or BitBucket, so you actually have to host your repo yourself

There are other DVCSs out there, notably including darcs and bzr, but I've not used them enough to have a worthwhile opinion on them.

Hank Gay
Nice comparison! I think the git integration matured in the last time.
EGit is better than it used to be, but still not as well integrated as svn into the eclipse ecosystem, hopefully it will improve further
Aaron Statham
You say that `git` has a steep learning curve, but I find it not that complicated at all. Free online book about `git` here:
Eclipse supports hg with MercurialEclipse plugin; IMO it is quite nice, and recent merge with hgEclipse has boosted its development.
@Jesper: Especially if you use git-gui
@Jesper the `git` commands don't make any sense unless you already know the underlying model. Many people don't want to learn about an underlying model: they want a nice clean abstraction. If you want a nice, *clean* abstraction, `git` is almost sure to disappoint. I forgive it for this largely because it is crazy powerful and people build awesome tools around it.
Hank Gay
+2  A: 

Your comment makes it seem like your real question is whether or not you really need to use version control, given that it's a one-person project.

It takes very little time to set up and use git or mercurial. Just do it. If you don't need it, you've lost a few minutes. If you do need it, it could potentially save you weeks.

+2  A: 

Git and Mercurial (hg) do have a lot of momentum as distributed source code repositories but in my opinion, for a one man band, you will find the most support with Subversion. If you are in Windows there's TortoiseSVN shell integration which is fantastic (it even integrates with Trac) and free Subversion hosting is all over the place and have some personal experience with (they do Git and SVN). Also, Subversion is pretty straightforward to get integrated directly into the Eclipse IDE.

+6  A: 

a/ It is necessary to have a VCS

b/ CVCS and DVCS are quite different

c/ Eclipse is currently moving all its project to Git (and is improving on EGit), so Git will be the VCS target on Eclipse.

especially a and c are really good arguments (why couldn't I find a in the first place?...)
+1 - this is the kind of thing the OP really wants to know.
Stephen C
@FloE: well, it's an old link, and I have been following the VCS topic for a long time on SO ;)
Agreed. But I would personally wait with Git until EGit 0.9 ships around September. There are some critically missing features in the current release and it is mostly recommended to people already using Git from the command line. The SVN tooling, on the other hand, is very mature and easy to use.
+1  A: 

There are many benefits from using a SCM instead of just Eclipse histoiry even for just a single person:

  • comments on commits: you can say WHY you did something. This will help you when you need to figure out why some code does as it does, based on its history.

  • backups: Oh, you messed up your Eclipse workspace completely? Just create a new one, and pull in a fresh copy of the code.

  • continuous integration: check that code builds after every save, runs tests (this is important), and creates the actual binary to send to the customer.

It is your safety net. Take the time to learn it, and use it right. You will end up liking it :)

Thorbjørn Ravn Andersen
these are some very strong arguments - exactly what I'm looking for :)
@Thorbjorn - if you are relying on your SCM as a backup for your Eclipse workspace, then it is also important that you have a proper backup regime in place for your SCM. Definitely on a different machine (in case your disc/pc dies), and preferably off-site.
Stephen C
@Stephen, as always there is no magic. This is very easy to do with git (just clone it), and rather tedious with svn and cvs.
Thorbjørn Ravn Andersen
@FloE, I have made it a habit that whenever the workspace for a given project gets enough messed up, then I create a new workspace and pull in the code anew (we use Team -> ProjectSet's for that). This requires a timestamp in the workspace name. That works very well, as it keeps the workspaces fresh and I get to exercise the "set up from scratch" procedure. That is valuable in order to get rid of arbitrary dependencies outside Eclipse
Thorbjørn Ravn Andersen