> Kẏra <kxra <at> riseup.net> writes: > > Can someone explain the difference between the patch theory behind darcs and that of camp?
Thank you Eric, Ganesh for your replies to Kẏra. (I have traced through the various references.) I note that IanL has recently withdrawn from his supporting role for ghc. Does that mean less activity on Camp? Or so that Ian can work more on Camp? The Camp project pages are a strange mix of very nitty-gritty detail about some technical aspects (like repo format), and very abstract 'theory'. I wonder what it means for a VCS to be "similar in philosophy to darcs", as Ian's 2012 draft puts it? For example, would the Loh/Swiestra/Leijen 'Principled Approach' count in or out? (They have what amounts to a GUID for every file being tracked, which is a proposal under Darcs3 for the AddAddConflict. What's more, they have a GUID for each line of the source text, to deal with conflicts at the line level.) Darcs, Camp, L/S/L have in common: + a repo is a multiset of patches + patches can be freely resequenced, providing no conflicts + any conflict-free resequence is equivalent (results in the same external representation) + so you can cherry-pick any patch into any repo (conflicts permitting) Where they differ is on how to resequence patches: * Darcs, Camp have an algebra for commuting * which needs 'adapting' a patch when commuting it (that is, in the 'interesting' cases) * and how that works depends on the two patches and by extension a whole chain of patches to get from source repo to target I see that many of the difficult parts of 'Darcs 3 Wishlist' are around this commuting and adapting. Issue 1786 says: "The problem is that whenever you want to define a new patch type, you have to define how that type commutes with all other patch types." L/S/L's approach is: * use a symbolic notation for all patches (such as a file GUID) * so that they don't need adapting for commute. * capture any dependencies 'inside' the patch. * there is an algebra to show that commuting preserves the 'moral effect' (providing no conflicts) This is in effect the same as the 'Darcs laws'. * Patches are held as sets of primitive operations on the repo, * so combining patches is set union of those primitives. [I know I'm over-simplifying there!] It seems to me that set-based operations, and avoiding the need to adapt patches on commute, would make it easier to introduce new patch types(?) without having to deeply understand what each type does(??) It might also make it easier to detect conflicts/dependencies as a set mis-match(?) So is L/S/L 'on the radar' for Darcs3? AntC _______________________________________________ darcs-users mailing list darcs-users@darcs.net http://lists.osuosl.org/mailman/listinfo/darcs-users
