Hi David, On Sat, Nov 15, 2008 at 16:25:41 -0500, David Roundy wrote: > Here's a fix for issue525, which turned out to be trivial.
Applied, thanks! But I confess that I don't fully understand this. resolve issue525: canonize output of sort_coalesceFL in AmendRecord. -------------------------------------------------------------------- > David Roundy <[EMAIL PROTECTED]>**20081115211925 > Ignore-this: cb7485c971d7d8d6f7ffce9f9ec40e98 > ] hunk ./src/Darcs/Commands/AmendRecord.lhs 193 > - in n2pia $ infodepspatch new_pinf pdeps $ fromPrims $ sort_coalesceFL $ > - concatFL $ > - mapFL_FL canonize $ oldchs +>+ chs > + in n2pia $ infodepspatch new_pinf pdeps $ fromPrims $ concatFL $ > mapFL_FL canonize > + $ sort_coalesceFL $ concatFL $ mapFL_FL canonize $ oldchs +>+ chs Do you think you could provide some examples of what a realistic non-canonical representation of a patch would be (compared to the canonical one) and also an explanation of why running sort_coalesceFL on them can result in their decanonicalisation? Also, is there any reason to still canonize the patches before we sort_coalesce them? Is this snippet from issue525 an example of a non-canonical patch? hunk ./ChangeLog 1 -2007-08-29 Alexey Shchepin <[EMAIL PROTECTED]> +2007-08-29 Mickael Remond <[EMAIL PROTECTED]> + + * doc/guide.tex: Documentation for XML based optimisation build + time option (EJAB-298) hunk ./ChangeLog 6 +2007-08-29 Alexey Shchepin <[EMAIL PROTECTED]> + With its canonical representation being something like the below? hunk ./ChangeLog 1 +2007-08-29 Mickael Remond <[EMAIL PROTECTED]> + + * doc/guide.tex: Documentation for XML based optimisation build + time option (EJAB-298) + If so, that makes me a bit confused about the relationship between coalescing and canonizing... -- Eric Kow <http://www.nltg.brighton.ac.uk/home/Eric.Kow> PGP Key ID: 08AC04F9
pgp0OpWh4MBG8.pgp
Description: PGP signature
_______________________________________________ darcs-users mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-users
