CVS is dead

Martin Marques martin at marquesminen.com.ar
Thu Dec 27 20:49:23 UTC 2007


Les Mikesell escribió:
> 
> CVS has problems caused by all of the history being kept in a single 
> file (it doesn't understand directory operations like renames), but the 

Oh, and the fact that commits are not atomic so that if two chagesets 
collide (well, CVS doesn't have notion of changeset, only of single file 
changes) very bad things can happen (one changeset locks a file that the 
other changeset has to update) and you get a corrupt copy that has to be 
fixed.

Subversion, git and Mercurial (and others) addressed this issue adding 
atomicity to the chagesets (see that with these VCS files don't have 
version there are changeset versions).

> up side is that you can track development 'forwards' from any point. 

Uhh???

$ hg up -r SOME_OLD_REV

(same with svn or git-update).

> With svn, there's no way to start from an earlier tag and follow future 
> tags/branches of that same file.  

What? Les do you really know what you're talking about?

> This must be even worse in distributed 
> VC's where the changes might not even exist in your copy of the 
> repository.  Doesn't it bother you to know you might be repeating 
> someone else's mistakes because you can't track all the other changes 
> from a given point?

What mistake if it's not in the repository?

The same thing would happen with CVS if you were coding without 
commiting to the main server. Nobody will be able to know what you are 
doing. Same if your coworkers don't update regularly. How can they know 
what you fixed?

In distributed VCS you use pull and push for this.




More information about the fedora-list mailing list