On Fri, Jul 14, 2006 at 07:39:13AM -0400, David Roundy wrote: > Ah, you mean the resolution is in conflict? I'm starting to think that > perhaps resolutions should never be in conflict. Well, there's one > case where they are in conflict. If they resolve a change that's > depended upon by a live change, then the resolution is in conflict > with that live change. But I'm starting to think that apart from that > issue, they should never conflict. They already require special merge > and unpulling rules (since they eat up other changes), and I think > that one can extend those so that a resolution can be merged with any > change (or sequence of changes) that has its same context, which will > be the case for any change that doesn't depend on its contents.
I've made an attempt at formulating this idea more clearly: Behavior of resolution patches ============================== A resolution of the sequence of changes ABC... generally commutes like the sequence ABC...C^B^A^, with the exception that two successive resolution patches always commute. When merging, a resolution patch will never conflict with any patch that has the same context, but will be held in the repository before that patch. This is unlike ``ordinary'' merging, in that this sort of merge may not be reversible by commuting. ... Unmerging ========= Since there will now be merges that are not reversible by commutation, I believe we will need to introduce some sort of unmerging or obliterating higher-level operation. I believe the semantics of this can be expressed by splitting the repository into a set of conflictnig branches prior to the change that needs removal, and then removing the offending change and checking to see if there is a conflict. Explanation: When we remove the change r(A) (``resolution of patch A'') from a repository, the change A, which was previously surpressed by r(A), will need to reappear. The semantics of which patches need to reappear I think are best expressed by asking oneself what the result is of merging all the patches in the repository except the one we wish to remove. The point is that, unlike the previous formulations of darcs, we cannot achieve this simply by commuting the patch we want to remove to the ``end'' of the repository and then removing it, since the patch A only exists hidden *within* r(A). Thoughts? -- David Roundy _______________________________________________ darcs-devel mailing list [email protected] http://www.abridgegame.org/cgi-bin/mailman/listinfo/darcs-devel
