[darcs-users] David's darcs

Petr Rockai me at mornfall.net
Wed Jul 22 17:16:37 UTC 2009


Hi,

Karel Gardas <kgardas at objectsecurity.com> writes:
> Petr Rockai wrote:
>> We'll have to agree to disagree. Incremental refactoring is good, if you have
>> working code. But the darcs core is quite buggy and very poorly
>> understood.
>
> I think what Jason tries to suggest is to write some more
> documentation/mini-spec, core functionality unit-tests just to solve
> your "very poorly understood" complain. Also it would be very good if
> you come with some proof to your claim "darcs core is quite buggy". As a
> darcs user I'm currently quite happy with it on small size projects (<
> 100MB source tree) but if the core of my favorite DVCS is buggy, then
> I'm getting nervous. Do you have any url to darcs bug database which
> will add some weight to your claim?
As long as you keep a low profile, you shouldn't hit most of the bugs. The
quite buggy part refers to general tendency of the code to spin (exponentially)
out of control under anything more complex than a trivial merge -- see the
droundy-vs-darcs.net merge as one example, or my lvm merge example from a while
back. The other is that divergent branches often trip a crash in darcs (yes,
some of those have been fixed, but definitely not all of them).

The darcs-2 core works great as long as you stay away from duplicate hunks and
complex conflicts. However, this is much weaker guarantee than we would
like. We want a tool that is robust under *all* conditions: no crashing or
hanging bugs please. If you need to tread carefully around your VCS, then
something is wrong (and we all do and we also want to fix that...).

>> Moreover, we don't even know if there is a polynomial solution to
>> the conflict resolution defined by the (implicit) theory behind darcs-2.
>
> The theory behind darcs is exactly what makes darcs unique. If you
> remove the theory you end with just yet another DVCS, nothing more I'm
> afraid. Are you suggesting that you are really going to remove just
> critical piece of darcs foundation? I hope not.

No, with theory I mean more rigorous definition of theory. There are many
"patch theories" possible: darcs-1 implements one of them, and darcs-2
different. And camp works on yet another, which will come formalised, unlike
darcs-1 and darcs-2, which only come in form of (somewhat under-documented)
code -- especially the darcs-2 case.

Yours,
   Petr.


More information about the darcs-users mailing list