I have just discovered bitbucket, and I love it! Version control, wiki, and bug tracking for free! I have always wondered about how to get some basic version control for my little code projects so I am blown away at getting a pretty professional environment with no more difficulty than, say, signing up for facebook.
I like it as well, especially because you can have private projects which (I think) github doesn’t support for free. Although git gets all the attention, Mercurial is a nice VCS that integrates well with eclipse.
If you don’t have money, Github is best for public repos with lots of collaborators and Bitbucket is best for private and public repos with at most 5 collaborators.
I acctually like the fact that github “forces” you to make your code public, because in 99% of all cases there is no rational need to hold it private.
For example, I have some code of mine on GitHub and only because it was public someone got interested and made me a job offering(asked if I would like to apply).
I still don’t understand Git and Mercurial 
Think I need someone to sit down and explain it all to me.
Cas 
People get religious about it, but as long as you’re using some kind of version control, it doesn’t matter much.
Distributed vs centralized in a nutshell means no more checkouts - everyone gets an entire copy of the whole repository. Ironically most workflows employ some sort of centralized/blessed repository.
Assuming you’re not a version control nerd at all - the immediate benefit you notice with distributed is that you can commit/branch/etc locally and choose when exactly your code is ‘live’ in the central repo. So you don’t have to work without the benefits of version control just because you’re offline or you think you might commit a broken build or something.
If you work by yourself, always have an internet connection, or don’t care about the state of the project on a per-commit basis, then you won’t notice many of the benefits.
The gist of DVCS is that you are the repo, the versions are stored locally. You then sync your repo with one or more other repos, either pushing, pulling, or both ways.
This gives you lots of speed since the repository ops are done locally, and lots of flexibility since every repo is an equal citizen. To support doing this stuff, most DVCS’s (Distributed Version Control Systems) have also made branching and merging much faster, more robust, and more featureful – features like shelve and rebase are something you won’t see in most centralized systems for example. This is its own benefit even if you never otherwise use the D part of a DVCS.
I always break my version control, they just didn’t roll back the way I want.
Ordinary version control like CVS and SVN all made perfect sense to me; the trouble is getting my head around the UI in Eclipse, to be honest. I suspect it’s buggy too so I fear it greatly.
Cas
The MercurialEclipse plugin is the most stable and easy to use CVS plugin I’ve found, which is why I use it instead of git.
I’m using Egit for some months now. I never had ANY problems. And it’s easy as SHIT: in the Package Explorer, hit right mouse button -> Team -> Do whatever you want. Everything works really easy. Oh, and I haven’t found any bugs yet. I don’t even expect some anymore.
Setting up is easy too:
Installing:
- go to Help -> Install new Software
- Write into the “Work with” field: http://download.eclipse.org/egit/updates
- Klick Add, select a name, for example “Eclipse EGIT” and confirm
- Open the Tab “Eclipse Git Team provider”
- Select “Eclipse EGit”
- Click “Finish”
- Agree to everything coming.
- Done.
Setting up first EGit Project / Turn Project into EGit-Project:
- In the “Package Explorer” (By Default, the File-Browser on the right), right-click on your Project
- Click on Team -> Share project
- Select “Git”, click “Next >”
- Create a repository if you haven’t got one. (Just click “Create” and pick a name and path, lol…)
- Everything is fine now. Click “Finish”.
- Your project is now a git-project
Before you commit your project, you might want to deselect “non-sources”, and “gitignore” them.
Git-Ignoring Folders/Files:
- Right-click on the file in the package Explorer
- Click Team -> Ignore
- Done. (! Usually this is really “hard” for git-newbes to do per command-line !)
Finally, to show, how cool EGit is:
First Commit:
- Go (again per right-click) to Team -> Commit
- Enter a commit message, and the files you want to commit, done.
I might go on, on how to integrate this whole stuff with github, but for these purpose, there is a tutorial (really really really good tutorial):
http://wiki.eclipse.org/EGit/User_Guide
Subclipse or Subversive? I find Subversive to be weirdly buggy, even though it’s the ‘official’ Eclipse one. I much prefer Subclipse (which is the ‘official’ SVN one).
Never had much trouble with Subversive - its more up to the SVN connector used in conjunction IMO (SVNKit, JavaHL, …). Especially with SVNKit I have seen widely varying results depending on which version is installed.
I’ll come out of the closet. I still use CVS. There I feel better.
I’ve used most VCSs over the years, but I seem to end up liking them all. Even Continuus had its good points. Git I like very much because it has colored text in my DOS box - that is soooo eighties.
I am sure there are plugins for my IDE but I’m perfectly happy running Git from the command line and not having any of the above grumbles about plugin bugs.
CVS is fine. Fiddly to merge though I seem to recall.
Cas
I very much love git from the command line. I hate git GUIs except for checking logs and merge history. The giant advantage git has over SVN and other older source control models is that you can make as many branches as you want extremely quickly. Want to try out a new feature? Make a new branch. Refactoring? Make a new branch. Easy peasy.
Just so you know, I support your right to form civil unions with other CVS users.
Do you use it for personal projects? From what I understand most complaints from CVS are when you have multiple people working on the same project and there’s a lot of complicated branching and merging going on. So single user projects are fine.
Don’t be ashamed, we’re here for you and we support you.