[darcs-users] David's darcs [Was: Re: darcs patch: ...]

[Jason Dagit]

On Tue, Jul 21, 2009 at 9:08 AM, Petr Rockai <me at mornfall.net> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osuosl.org/pipermail/darcs-users/attachments/20090721/133e1f7a/attachment-0001.htm>