On Tue, Jul 21, 2009 at 9:08 AM, Petr Rockai <[email protected]> wrote:
> Hi, > > I know this has been lying around for a while. I took the time today to > investigate in what shape David's darcs branch is. It claims to fix > issue1014 > (and I believe it does). However, doing "hard" merges, David's darcs now > hangs > even before asking for patches, making exchange of patches between > hard-to-merge repos impossible (even for the easy patches). I believe this > is a > side-effect of the refactors and is something we would better wait to be > resolved. Just curious, what is a "hard" merge? Computationally difficult or is it a forceful merge? If someone could look into why that hangs it would be valuable information I suspect. I bet David would be interested in that bug report, for instance. > > > The other, more important issue is that neither our nor David's darcs is > able > to merge the repositories in any reasonable time. I gave both about 30 > minutes > of CPU time to try the merge, and also tries a number of simpler pulls > without > any useful results. Moreover, both exhibit the "mergeConflictingNons failed > in > geteff with ix' bug. If you run the ghc profiler on this merge, do you know where we spend all the time? > > > This basically means, that unless either of the darcsen fixes those > exponential > bugs (and the mergeConflictingNons one) that the branches are divorced. That's unfortunate. We should at a bare minimum abort gracefully without making the user wait a week. When other vcs fail they tend to fail quickly. So even when they don't do what you want and you resort to diff + patch, you can find out soon enough that you're not wasting a bunch of time waiting on a something that will never happen. > > > There are likely some choices: > - abandon current darcs core altogether Could you clarify how you define 'darcs core' in terms of modules? > > - try to fix it ourselves It sounds like you've looked at this the most recently, do you have any ideas on how the fix would go? get_extra has always been a nasty little bit of code. I've tried to document some of the assumptions I'm aware of in that bit, but I've always suspected it to be a little brittle. It's also crucial to optimize that code because it is such a common code path and needs to do some real work. > > - try to merge David's work manually (and hope that he eventually fixes the > bugs in the core we care about) A manual transplant (aka diff + patch) may be a good idea. > > > I am starting to think that it would make sense (at least for me) to finish > some work on the 2.4 release (with the current core), and then focus on > moving > along. The current darcs core is, unless major changes occur within the > development team, as good as dead. I'm not sure what you're saying :) You feel the current core is dead; okay fair enough. But, what are you proposing beyond asserting its death? Are you saying someone needs to rewrite it? Rewriting the core comes with a big burden of backwards compatibility. You could bump the repo format number (like we did with darcs2) and we could go through the process again with a darcs 3 format. But, other approaches, like rewriting all the core code while calling it darcs-2 format is risky because you could end up with different semantics (before and after the rewrite) for the same repo format. We also probably want to maintain the current code for quite a while so that we have true backwards compatibility with previous repo formats. Again, like the darcs-1 format to darcs-2 format transition. I like the idea of the core getting attention and cleanup. In particular, I would love to see what impact there is to switching to a left fold based io system (the Oleg iteratee stuff). It's a massive rewrite as near as I can tell, but I think it would give us more explicit control over the algorithms and allow us to fine tune our performance better. My intuition is that we could apply the iteratee approach to both streaming data from the harddrive/network (for parsing) and also to the task of streaming patches from the repository (after parsing we generate patch sequences in an iteratee fashion). I seriously doubt I will work on it. I love darcs, but I'm unable to use it at my day job and recent side projects I have started required other vcs for various reasons. In other words, my motivation for such a large undertaking is rather small right now. Additionally, Darcs meets all my needs on the few darcs repos I use it with. Jason
_______________________________________________ darcs-users mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-users
