On 6/11/07, Jason Dagit <[EMAIL PROTECTED]> wrote:
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?
1.0.9rc2 at the time, when trying to merge patches from two local branches. That is: Given a shell script: #!/bin/bash # # mknchdir <path> mkdir -p $1 pushd $1 I did this: $ cd foo $ # hack hach hack $ darcs init; darcs add --recursive * $ # hack a little.... $ popd $ darcs get foo bar $ darcs get foo baz $ cd bar $ # hack on bar for about two weeks. $ cd ../baz $ # hack on baz for about two weeks. $ cd .. $ darcs get bar combined $ cd combined $ darcs pull ../baz ZZZZZzzzzzzzzzzzz.......... As you can see, nothing really exotic. And, I knew that I'd have to resolve conflicts in the process. But, for whatever reason, darcs decided to solve the halting problem. No remote repositories were harmed in the making of the e-mail.
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
At my place of employment, our project is about 4x the size of Linux's repository, all total. :( It took git a solid 35 minutes just to _import_ the project into the local repo. It was pretty zippy once imported though. I mentioned that it was stable because it has to be operator error. But, after reading the documentation for hours, I still must not have grokked something because it behaved differently from my expectations. This isn't necessarily a bug. After all, it's in use by the Linux kernel developers. And with 4 merges a day, I would _expect_ that "git push" and "git pull" do work, somehow. Still, this raises something very, very important. Darcs has a _vastly_ superior user interface. And that, alone, is why I want darcs to "win" over git. :) It has that distinct "It Just Works"-ness to it. Usually.
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.
True, and again, I can deal with this through other means. I always have been. Indeed, the fact that darcs doesn't grok Unix file attributes of any kind means I can't use it for the all-encompassing tool, which is a real pity for me. But, I've adjusted. Provided it doesn't hang itself in the process, that is. :D
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
I have Haskell experience, but I'm far from expert. I am using it on my next generation of CUT though. It's the project that taught me the language as well as how to (more or less) efficiently deal with strings.
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.
My problem is time, not experience. I understand Haskell, though I don't understand Darcs' source structure, or the algorithms used. Any "big project" needs, minimum, 6 months of acquaintance time, I've found. Still, what would extra developers bring to the table? What's needed most, I think, is the ability to reproduce bugs. It's the intermittent bug that kills. :) -- Samuel A. Falvo II _______________________________________________ darcs-devel mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-devel
