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
pgpr6ChSnKlNV.pgp
Description: PGP signature
_______________________________________________ darcs-users mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-users
