Hi Adam, This looks like a nice little case study for the ConflictsFAQ. I am going to walk you through my attempt at resolving these conflicts, including my false starts.
If this mail helps you out in any way, I would appreciate it if you could attempt to improve our conflicts FAQ. No specific requests, just try to make it so that it would have helped you sort things out. http://wiki.darcs.net/index.html/ConflictsFAQ This looks like a textbook example of a conflict fight. Unfortunately, in this particular case study, we are up for a little bit of work! Preflight ========= First of all, it appears that there are some unrecorded changes in your working directory. These seem fairly easy to resolve, so I'm recording them a patch. Simplify! simplify! =================== It seems that you can cherry pick the 2nd patch without any problems. Fri Nov 2 01:07:02 CET 2007 [EMAIL PROTECTED] * bugfix Where is the conflict? ====================== darcs pull --verbose tells some interesting things about these two repositories, notably that there are only two of their patches to pull (now that we have simplified the situation by pulling in that third patch) and that we only have 3 patches that they do not. In other words, this might not be such a horrible situation to deal with after all. darcs pull --verbose --dry-run > /tmp/pull-output -------------------------------------------------- We have the following new (to them) patches: Fri Nov 2 03:35:41 CET 2007 [EMAIL PROTECTED] * HonorsLab07 - Emitting Pseudo-Assem Thu Nov 1 03:10:43 CET 2007 [EMAIL PROTECTED] * preparing for Emit lab Tue Oct 30 20:03:05 CET 2007 [EMAIL PROTECTED] * everything up to and including first parser lab They have the following patches to pull: Sun Nov 4 20:10:08 CET 2007 [EMAIL PROTECTED] * fix handling of unary prefix operators Thu Nov 1 23:04:32 CET 2007 [EMAIL PROTECTED] * update test cases darcs pull --dry-run --summary ------------------------------- This gives us an idea what we're dealing with on the other end Thu Nov 1 23:04:32 CET 2007 [EMAIL PROTECTED] * update test cases ./misc/test.char.c -> ./misc/test.01.char.c ./misc/test.char2.c -> ./misc/test.02.char.c ./misc/test.localvar1.c -> ./misc/test.05.localvarc <snip> A ./misc/test.01.char.pseudoasm A ./misc/test.02.char.pseudoasm <snip> R ./misc/test.sizeof2.pseudoasm R ./misc/test.string.literal.pseudoasm Sun Nov 4 20:10:08 CET 2007 [EMAIL PROTECTED] * fix handling of unary prefix operators M ./Makefile +1 A ./misc/test10.c A ./misc/test10.pseudoasm M ./src/Parser.java -2 +17 We could also have done this using darcs changes -s --repo http://research.cs.berkeley.edu/class/cs/61c/labs/61ch-labs but it would have been trickier, since we would have had to specify which patches we wanted. There's no getting around that on the local end, however: darcs changes -s -p 'everything up to' -------------------------------------- Tue Oct 30 20:03:05 CET 2007 [EMAIL PROTECTED] * everything up to and including first parser lab M ./Makefile +2 A ./misc/test8.c A ./misc/test8.pseudoasm A ./misc/test9.c A ./misc/test9.pseudoasm M ./questions/lab02.txt -1 +7 M ./src/Lexer.java -7 +237 M ./src/Parser.java -16 +88 darcs changes -s -p 'preparing for Emit lab' ------------------------------------------- Thu Nov 1 03:10:43 CET 2007 [EMAIL PROTECTED] * preparing for Emit lab M ./Makefile +3 A ./misc/test8.c A ./misc/test8.pseudoasm A ./misc/test9.c A ./misc/test9.pseudoasm darcs changes -s -p 'HonorsLab07 - Emitting Pseudo-Assem' --------------------------------------------------------- Fri Nov 2 03:35:41 CET 2007 [EMAIL PROTECTED] * HonorsLab07 - Emitting Pseudo-Assem M ./src/Parser.java +11 Simplify some more? =================== It seems that we can also cherry pick 'fix handling of unary prefix operators' with relatively little trouble. This generates a small conflict in the Makefile, which we can resolve easily. But hey, wait a second, didn't I see that those Makefile lines before? These were lines touched by two previously conflicting patches, very likely the 'preparing for Emit lab' and the 'everything up to' patches. Perhaps these patches are responsible for a lot more conflict than they are worth. Let's see what life would be like without one of them, say 'preparing for Emit lab' because it is the smallest. Plan B ====== # cd .. # darcs get 61ch-labs 61ch-labs-try-conflict # cd 61ch-labs 61ch-labs-try-conflict # darcs obliterate Tue Nov 6 02:21:43 CET 2007 [EMAIL PROTECTED] <== actually Eric Kow here * Resolve conflict in Makefile. Shall I obliterate this patch? (1/?) [ynWvpxqadjkc], or ? for help: y Tue Nov 6 02:17:31 CET 2007 [EMAIL PROTECTED] * Conflict resolution Shall I obliterate this patch? (2/3) [ynWvpxqadjk], or ? for help: y Thu Nov 1 03:10:43 CET 2007 [EMAIL PROTECTED] * preparing for Emit lab Shall I obliterate this patch? (3/3) [ynWvpxqadjk], or ? for help: y Finished obliterating. # darcs pull http://research.cs.berkeley.edu/class/cs/61c/labs/61ch-labs Thu Nov 1 23:04:32 CET 2007 [EMAIL PROTECTED] * update test cases Shall I pull this patch? (1/1) [ynWvpxqadjk], or ? for help: y Finished pulling and applying. Awesome! Now all we need is to see if any changes from that 'preparing for Emit lab' patch need to be merged in. Merging... automatically? ======================== You could try pulling that 'preparing for Emit lab' patch in (ignoring the conflict resolution patches), but that seems rather slow as well... Merging by hand :-( =================== darcs diff --repodir=../61ch-labs -p 'preparing for Emit lab' --unified > /tmp/emit.diff patch < /tmp/emit.diff Inspect the results, darcs record a new patch. And if satisfied, discard the original 61ch-labs (hopefully, noone else is using a copy of that repository) Sanity check ============ * No more patches to pull on the other end, right? * Nothing in darcs whatsnew -- Eric Kow http://www.loria.fr/~kow PGP Key ID: 08AC04F9 Merci de corriger mon français.
pgpV48l7TjVmY.pgp
Description: PGP signature
_______________________________________________ darcs-users mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-users
