CVS is dead

Les Mikesell lesmikesell at gmail.com
Thu Dec 27 23:19:34 UTC 2007


Martin Marques wrote:

>> 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

Start from a tagged point in development. Branch several times for 
different changes. Can you find all subsequent work?

> (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?

I'd like to hear that I don't.  With CVS, if you have any of the 
development you have all of it.  With svn, tags are (by convention) dead 
end snapshots and there is no way to track forward development.  Assume 
you worked on something some time ago, ending by creating a certain tag. 
  Now several other people create branches for additional work.  How can 
you tell that, starting from the tag you last knew about?  You could 
start from any of the branches and work backwards but you can't see what 
branches were created or when going forwards.

>> 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?

That's the point - you won't know.

> 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?

If you aren't committing to the central repository, you aren't using CVS.

> In distributed VCS you use pull and push for this.

How can you tell whether that was always done or not?

-- 
   Les Mikesell
    lesmikesell at gmail.com




More information about the fedora-list mailing list