WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] Bitkeeper

Sean Perry wrote:

Haskell is a bit slower, but the real culprit is design related. The author and crew are working on it. Should be cleared up eventually.

Hmm, the Wiki page about darcs performance looks rather scary:

http://www.scannedinavian.org/DarcsWiki/Performance

And quoting from the "Best Practices" page at

http://www.scannedinavian.org/DarcsWiki/BestPractices :

"Also, very large conflicts and complex conflicts can cause darcs to use an exponential amount of CPU power to solve the problem, giving the appearance that darcs is "spinning" or "hanging""

From what I have read about darcs, the problem is the 'theory of patches' approach which demands that all patches be loaded into memory at once so that the order in which they should be applied can be determined via a n*n comparison of the contents of each patch against the contents of all other patches. While all this talk of quantum operators may sound sexy at first, I am fairly sure it is vastly overkill for real-world source-control.

I other words, I would not be too optimistic about darcs having its performance issues cleared up in the shorter term. Besides, there is the issue of using a tool written in a language that the majority of programmers will find hard to understand*.

Jacob

* Not me of course, I was exposed to Miranda at an early age ;-)

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

<Prev in Thread] Current Thread [Next in Thread>