If I don't solve the testing problem, I'd suggest applying this patch bundle in time for darcs 2.5 alpha
On Sun, Jun 13, 2010 at 19:09:31 +0000, Reinier Lamers wrote: > Here's a review of patch 258. Before pushing it, I'd like to know if it's > intentional that all tests that the bundle adds pass, even when I apply only > the new tests. Ah sorry about that! I've had a look, and to be honest, I'm slightly confused because I distinctly remember failing bits when you apply some subset of the bugfix patch but not the whole thing. But I can't reproduce it. > Use the new format when reading conflictors using the ReadPatch instance for > RealPatch (which is the darcs-2 patch type afaik). That's my understanding too, as documented in http://wiki.darcs.net/DarcsInternals/Patches We've inherited the Darcs code from one maintainer. We must learn it. It will take some time. > And also use the new format when reading inverse conflictors using the > ReadPatch instance for RealPatch. I wonder if we'll ever see inverse conflictors in real life. > >+# nons > >+cd S3 > >+echo hello >> kitöltés.lisp > >+darcs record -a -m "My conflicting edit" > >+echo hello >> kitöltés.lisp > >+touch non-kitöltés.lisp > >+darcs add non-kitöltés.lisp > >+darcs record -a -m "My continuation of the conflict" > >+darcs pull -a ../R > >+darcs pull -a ../R > >+cd .. > > Add 3 more scenarios. I don't understand what the third one wants to check. > It > has a conflicting edit and then records something unrelated to a file named > non-kitöltés.lisp. Is that when Non's arise? I confess that this was sort of random because I didn't really understand the patch structure well enough. It was just me trying to make something complicated happen. I think what I was vaguely after was the context part of a Non patch. conflictor [ hunk ./kit<U+00C3><U+00B6>lt<U+00C3><U+00A9>s.lisp 2 +hello ] <-- the stuff that would go here |: hunk ./kit<U+00C3><U+00B6>lt<U+00C3><U+00A9>s.lisp 2 +hi So I'm going to see now if I can construct such a scenario. > What's more, all 3 tests succeed for me even when the other 2 patches have > not > been applied! Is that intentional? No, sorry! :-/ I suspect at this point I was no longer relying on the test per se but just looking at the darcs changes output on {S,S2,S3} before and after this patch. They should output something consistent for the filename (keeping in mind that this is just a *read* test). To make the test fail, I'm going to throw in a test that runs uniq on the filenames listed in the darcs changes output making sure we only get one filename. -- Eric Kow <http://www.nltg.brighton.ac.uk/home/Eric.Kow> PGP Key ID: 08AC04F9
signature.asc
Description: Digital signature
_______________________________________________ darcs-users mailing list darcs-users@darcs.net http://lists.osuosl.org/mailman/listinfo/darcs-users
