[CUWiN-Dev] [wiz@NetBSD.org: Comparison between different distributed vc systems]

[David Young]

Interesting article at the URL below.  I like Subversion well enough
for small repositories, but it still won't hold our NetBSD sources.
Anybody used darcs?

Dave

----- Forwarded message from Thomas Klausner <wiz at NetBSD.org> -----

Date: Mon, 14 Aug 2006 01:13:51 +0200
From: Thomas Klausner <wiz at NetBSD.org>
To: tech-repository at NetBSD.org
Subject: Comparison between different distributed vc systems

http://changelog.complete.org/posts/528-Whose-Distributed-VCS-Is-The-Most-Distributed.html

First few paragraphs:
Lately I have been trying out a number of distributed version
control systems (VCS or SCM).                                
                                                             
One of my tests was a real problem: I wanted to track the    
Linux 2.6.16.x kernel tree, apply the Xen patches to it, and 
pull only specific patches (for the qla2xxx driver) from     
2.6.17.x into this local branch. I wanted also to be able to 
upgrade to 2.6.17.x later (once Xen supports it) and have the
version control system properly track which patches I already
have.                                                        
                                                             
But before going on, let's establish what it means to be an  
ideal distributed VCS:                                       
                                                             
  * 1. The fundamental method of collaboration must be a     
    branch. A checkout should mean creating a local branch on
    which a person can commit and work without having to     
    involve the server. An update from some central server   
    should take the form of a merge from that branch to the  
    local branch.                                            
  * 2. Branching should be cheap. It should be easy to create
    a local branch, the operation to do so should be fast, an
    it shouldn't take an inordinate amount of space. It shoul
    also be as easy as possible to branch from a remote      
    repository.
  * 3. Merging between branches is intelligent. It should be 
    easy to merge another branch with your own. The VCS shoul
    know which changesets from the other branch are already o
    yours, and should not attempt to merge changesets that yo
    have already merged previously.                          
  * 4. Inividial changesets should be mergeable without      
    bringing across the whole history. You should be able to 
    bring across the minimum number of changesets necessary t
    effect a specific change. This corresponds to my test cas
    above. Future merges from the whole branch should, of    
    course, recognize that these changesets are present      
    already.                                                 
  * 5. Branching preserves full history. A branch should be a
    first-class copy of a repository, even if the repository 
    is remote. It should contain the full history of the
    branch it was made from, including diffs for each        
    individual changeset and full commit logs, unless        
    otherwise requested by the user.                         
  * 6. Merging preserves full history. A merge from one branc
    to another should also preserve full history. Changesets 
    merged to the local branch should retain the individual, 
    distinct diffs and commit logs for each changeset.       
There are also some things that we would generally want:     
                                                             
  * 7. It is possible to commit, branch, merge, and work with
    history offline.                                         
  * 8. The program is fast enough for general-purpose use.   
                                                             
                          Evaluation
                                                             
Let's look at some common VCSs against these criteria. I'll  
talk about Arch (tla, baz, etc), bzr (bazaar-ng), Darcs, Git,
Mercurial (hg), and Subversion (svn) for reference.          
...

----- End forwarded message -----

-- 
David Young             OJC Technologies
dyoung at ojctech.com      Urbana, IL * (217) 278-3933