use GIT Mate, use git

Just join the bickbucket.org and you will see how strong the GIT force :)

Git works on Windows, Linux, Ubuntu, Mac. Several plugins could be found to NetBeans, Eclipse and others.

On Amazon AWS EC2 takes minutes to get setup.

Supported by Assembla, Bitbucket, Github Repos.

So I don't think push people toward CVS is good idea.

PIECE

There seems to be a misunderstanding. Nobody is pushing anybody to use CVS. We all know how Git is much more popular. That is what the article shows.

I just explained that I use CVS because I got used to some features that CVS provides but Git doesn't, but those features may not be important to other developers.

Also as mentioned in the article, you do not need to host your Git repository in a public site like BitBucket, GitHub, etc. unless you want to make your projects publicly accessible.

True, you dont need to host your code online unless you are working with other people or want to make it public.

In git's case just by entering a directory from a terminal and running 'git init' it will automatically get version controlled. Later remote servers can be added to publish the code or for backup reasons.

Is also true that git hash system is more complicated than that of CVS or SVN where a simple integer number is increased and used to differentiate revisions. Is much easier to work with numbers like 100, 1000 than a hash like 00382d4bac3026637fa3f3be7a5d77ec0ac8a499

Right.

Talking about Git using a SHA1 hash to reference files, I am afraid that may cause collisions soon or later.

SHA1 generates 20 byte hashes. Any file with more than 20 bytes can have a hash that may be exactly the same as another totally unrelated file and may cause file confusion.

Git also uses the file length to compute the hash but that does not avoid collisions.

Another details is that if you change a file and then get back to the an older revision, both the new version and the older revision have the same hash. This way you do not know if a file with a given hash is the newer and the older revision.

These facts should not prevent anybody from using Git but they raise some concern about project file version confusion.

I think git has more advantages than others, sha1 ok only 20 byte :) . So if there is something wrong, git reset {last_working_commit} and problem solved. I wrote that comment because I think git is much more popular than others, and when I bring my kids to the Museum I always warn them this was passed.

The point is lot of developer think FTP is easier than Version Control. But isn't.

I think git, it's submodule, branches, merge, comments, hooks etc should have much more focus than something what is easy and there is primary_id, which isn't secure, for example one digit left out in copy.

I'm too busy to reply more, sorry. Moreover it is not my desk to polishing git. ;) I just use it cross my projects and I'm very very happy with that in all of my dev environments in Mac, Ubuntu and Window7.

The 20 bytes of SHA1 stands for 1.5*10^48 different hashes. So the chance of a collision is approximately 1/1,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000. So while it's possible to cause a collision it's very very ... very unlikely.

When you work with git you work with commits. If you change a file and then change it back you'll get two different commit-hashes. Even if two commits produce the exact same file content in all files in all directories their hashes still would differ because of different timestamps, authors, parent-commits and so on. You're right, files with the same content share the same SHA1. But you really don't work with file SHAs. You don't need them. You can't get a look at them easily. They're only an implementation detail.

The mindset in CVS is that of "versioning single files"/"file versions". Subversion (and others) fixed it to reproducible checkout releases/revisions. Subversions biggest flaw on the other hand is "a branch is a copy of the repository". This is the main cause of problems when merging. Git (and others) fixed that with a DAG data structure of commit objects which made it trivial to find the common ancestor(s) (unbelievable it wasn't used before).

And one of the avantages of a DVCS is, because you work locally, you can cope grind commits again and again until they're good enough before sending them upstream. And with git especially you can prepare commits in the staging area and leave other changes out for later.

Right the probability is very low, but unlikely does not mean impossible, so eventually it will happen.

The consequence of two different files having the same hash is that one will be confused with the other. This means that at least one file will be corrupted.