Hello! On 6/11/07, Samuel A. Falvo II <[EMAIL PROTECTED]> wrote:
I don't mean to whack a hornet's nest here, but recently I've had a very disturbing issue with darcs where it corrupted its repository on a company project. I found myself in a situation where I needed to fork a single project and merge them at the end (I was hacking in both forks independently). Upon merging, darcs would go off the edge of the world, never to be seen again. It was a genuine infinite loop -- left for hours, no RAM consumption was measurable. I'm not sure why, and have _not_ been able to replicate it since.
So the CPU was being consumed but no ram? Is it possible darcs was waiting on another process that was hung like ssh? (If the processor was going at 100% or you were doing everything on the same file system this wouldn't be the case.) Do you know which version of darcs you're using?
Considering I was using this for company proprietary code and data, I decided to give git a try. Heck, it works for the kernel developers, so it has to work for my meager amounts of code too, right?
If you like darcs but want to try something else I would have reached for monotone (probably also slow) or mercurial. I remember reading something a while back about git not always doing the right thing with histories. Bit of a design problem if I recall correctly. I think one of the monotone developers pointed this out to me.
What kind of SCM tool behaves like THAT?! Christ, even CVS works better than this. However, git has something darcs doesn't yet have -- stability and speed.
Given your experience with git I don't understand why you give it points for stability. Sounds to me like it did the wrong thing plain and simple. I have a hard time thinking of that as stable. If I were in your shoes I wouldn't trust git.
I would like this e-mail to be interpreted as a plea, to all developers involved, that stability issues need to be worked on.
Yes, buggy software isn't fun for anyone. Stability is important and taken seriously by darcs developers I assure you. Unfortunately, all software has bugs and version control is no exception. The problem with version control is that people really need to able to depend on their data. In that sense, version control needs to have the same robustness as file systems and databases. The reason David rewrote darcs in Haskell (originally it was C++) was to reduce the number and frequency of defects in the darcs code base. Stability has been on the mind of the developers since the very beginning. I'm currently refactoring some of the darcs core code to further exploit advanced extensions of the Haskell type system to reduce the likelihood of bugs in the patch handling code.
I can deal with the speed issues, as long as the stability is there. But, don't ignore speed all-together. I think the biggest reason for git's popularity is its performance (Linus claims 4 merges per day, which considering the size of the Linux repository, is quite impressive).
I had a conversation with David once where he made a very good point about the speed of darcs on repos like the linux kernel. How many projects out there are the size of the linux kernel in terms of code base, history and number of contributors? I think the current goal is to get darcs working flawlessly on the common case of repositories and then maybe we can scale it on up to handle linux sized code bases.
I really wish I had the knowledge to be able to contribute to darcs in a way more significant than this "customer testimonial" and "market research findings."
Bug reports and feed back are very valuable. It sounds like you're a programmer. Assuming you don't already program in Haskell, I would estimate it takes 1-2 years of studying Haskell in one's spare time to become proficient enough to hack on darcs. Even faster if you have lots of spare time. New developers are always welcome. Thank you for the feedback, Jason _______________________________________________ darcs-devel mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-devel
