[darcs-users] Darcs for GHC [was: darcs weekly news #28]

[Eric Kow]

On Thu, May 14, 2009 at 10:19:19 +0100, Simon Marlow wrote:
> Yes, exactly.  We want to work on branches and merge with the HEAD  
> regularly.  Darcs doesn't support this well because:

>  - conflicts are painful to resolve due to
>    (a) unhelpful conflict markers

The current thinking is that the changes which Ian's darcs-3
modifications to patch theory require will make this a lot easier to
implement.  So it's not so much the difficulty that's causing us to
hold off on this as it is the idea that we would be working much more
efficiently if we did it in the darcs-3-core-then-conflict-marking
order.

In the meantime, I think it it would be useful if somebody could lead a
discussion on how good darcs-style conflict marking should work on a UI
level.

>    (b) 'darcs changes' not telling you which patches conflict with
>        each other

Hmm: I'll bet we have a bugtracker entry on this.  Anyone?
Ian: any thoughts on how difficult this would be to implement in darcs
2?

>  - nested conflicts lead to, if not exponential, at least very slow
>    performance.  (admittedly I don't have hard evidence because I've
>    learned to avoid doing this now, but anecdotal evidence suggests
>    this is true).

I confess that I still do not have a strong grasp of conflicts, but my
current understanding is that all conflicts-related problems
(performance wise) are ultimately about nested conflicts (for example,
that the infamous darcs-1-format doppelganger patches are just patches
which are ideally suited for generating nested conflicts).  My
"understanding" continues in that darcs-2 improves the situation by
avoiding most of the common triggers for nestedness, but not all.  The
main bad nestedness is when you have a conflict and you don't push the
resolution patch to the other side.  On the other hand, Petr has
recently submitted another example of nestedness which does not involve
this scenario...

> In git we would either rebase regularly (if the branch wasn't shared) or  
> merge regularly (for a shared branch).

When you say merge, you mean pull stuff in from HEAD, right?

> transplant is something I/we want too.  Occasionally we need to pull a  
> patch into the stable branch, but without (some of) its dependencies,  
> and we'd like something sensible to happen - e.g. a conflict that you  
> have to resolve.  I think Ian and I exchanged a couple of messages about  
> this on this list a while back.

-- 
Eric Kow <http://www.nltg.brighton.ac.uk/home/Eric.Kow>
PGP Key ID: 08AC04F9
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: <http://lists.osuosl.org/pipermail/darcs-users/attachments/20090515/d0c79a01/attachment.pgp>