CVS SVN Git, What should I use for a project?

Question

I have never created a project using these, i had once used CVS for a project and it was greatly simple, just change or add things and commit them. Now i have written some project and i want those sources to be published and changed through the ways i mentioned above. I have created a github account but Git seemed too complicated for me, created one sourceforge account but i couldn't find how to create CVS project. So i am really stuck. So I need help. As I told, CVS was really simple, can you explain me how to create a CVS project and upload my whole project on it ?

Answer 1

Use a Distributed Version Control System (DVCS). I don't particularly care which one. I prefer Git; others prefer Mercurial; still others prefer Bazaar; and there are other options.

The advantages of DVCS systems over centralized version control systems (a la CVS or SVN) has been exhaustively documented all over the place. It's actually difficult to avoid stumbling across these posts, many of which say things like, "there are almost no disadvantages to using a distributed version control system over a centralized one."

Of course, "almost no" doesn't mean "precisely zero". There are disadvantages if you use large binary files or have an extremely long commit history. All the same, it doesn't sound like you're writing for an enterprise and likely won't encounter these problems.

Personal projects are perfect forays into DVCS. Documentation is rich. User communities are strong. Many authors of open source projects on your side.

In sum: Hop in. The water's fine.

Answer 2

You've overlooked another possibility, which is Mercurial. It's a distributed version control system like Git, but simpler to use.

Answer 3

DVCSes like git / mercurial (hg) / bazaar (bzr) are probably the way to go.

However, they have one big drawback wrt CVS and SVN: most DVCS, as of 2013, do not really support checkin and checkout. Many have partial rep work-in-progress, but sometimes have kluges such as copying the whole history and then checking out only a subtree. (Whereas what you want is to clone a partial history as well as a partial working tree.)

With CVS you can do partial checkin and checkout, simply by checking out a subdirectory.

SVN makes it even easier, arguably.

With CVS, you can create a single workspace out of multiple repositories by by arranging symlinks to different filesystem repos, and/or by checking out network repos, so that you can check in all changes to wherever they belong as one command.

SVN imports make this even easier.

Again, DVCSes are beginning to do this, but the support is clunky to say the least.

Overall, I recommend using a modern DVCS, but it is worth noting that there are certain usage models that modern DVCSes, as of 2013, just don't understand.

Worse, many DVCS developers simply don't understand these usage models - although I will note that I mentioned my problem to Linus once, and after he asked a few questions he said "Yes, I understand what you want; git doesn't do that; you should add it as porcelain."

The main usage model: when your project boundaries are fluid. You are starting out code that quite likely eventually will go into a library for reuse in other projects - and you are constantly moving files around. And where you don't want those other projects to have to get the full history.

My home directory is like this: many libraries that I reuse partially. But I seldom want my whole home directory tree cloned at a new site, just a subset that depends on what I am working on.