Alice wants to start from the most recent revision, 22, to implement the new sorting algorithm. To do that, she creates a branch in her own archive email@example.com. She will create a branch called sort.bob.quick to denote that she is working on a quicksort implementation. To create the branch, she starts by typing
As Alice and Bob continue improving their respective branches, they can continue to merge with each other with merge.
The algorithm that ArX uses to classify a path is:
Type Stored in Archive? Created by tree-lint warning? source Yes User No control Yes ArX No ignored No User No unrecognized No User/ArX Yes
If you're using an up-to-date version of emacs (I mean the original GNU Emacs, I'm not sure about xemacs), it should enter diff-mode automatically when you visit the .rej file. From there, there are several useful commands you can use, for instance, putting the cursor in a diff `hunk', and pressing `C-c C-c' will attempt to jump to the corresponding location in the source file; typing `C-c C-a' while in a hunk will try to actually apply the hunk (and will fail if it can't). Applying a hunk from diff-mode sometimes succeeds where patch failed, though I'm not exactly sure why, as it's actually more strict about matching the original file (it doesn't do `fuzzy' application).
So for instance a typical strategy I'll use is:
(1) Visit the .rej file in emacs; this will automatically be in diff-mode
(2) Make the buffer writable so I can modify the .rej file; this is just my personal style, you don't have to do this. diff-mode by default makes the buffer read-only, but I like to delete each hunk successfully applied, to make bookkeeping easier for big .rej files.
(3) Use the command `M-U' first, which converts the .rej file into `unified diff' format, which I find easier to read; again this is not necessary though, just something I like (and of course the buffer must be writable from step (2) to do this!).
For each hunk:
(3) Use C-c C-a to try to apply the hunk; if application succeeds, delete the hunk from the .rej file with `M-d' (.rej buffer must be writable to do this), and go on to next hunk, otherwise:
(4) Use C-c C-c to find the source location – this command will use line numbers as a backup strategy, so it usually gets you at least close – and see if there's some obvious problem where the source file has change from what the patch is expecting.
(5) If there's an obvious difference, say added code in the hunk's context lines, _modify the hunk_ to match the source, making sure any new lines you add to the hunk include appropriate diff line-start characters (' ', '+', '-'). diff-mode will automatically make sure that the hunk line counts etc are kept up-to-date. Of course this requires care, but I find it easier to think about the interaction of changes if I keep the source file unchanged and update the hunk. If the hunk then applies, then delete it and contine as in step (3).
(6) Sometimes diff generates really big hunks, which include many individual changes, and are difficult to think about as a whole. For these, I often use the diff-mode `C-c C-s' command, to split the current hunk into two smaller hunks at the current line (this only works in unified diff format, for obvious reasons), and then deal with each smaller hunk individually. Sometimes, if you're not sure where the problem in a big hunk is, you can use C-c C-s to do a binary search for the mismatch point (and use emacs' undo command to undo any split that's not useful).
The above might sound a bit complicated, but really it's not to bad once you know the diff-mode commands.
The crucial thing I think, is that it's _much_ easier to handle non-trivial conflicts with proper .rej files, compared to CVS conflict markers. the main reason I think, is that patch is more conservative, and requires a certain amount of surrounding context to match for a patch to be applied, and includes the failing context in the .rej files so you can see what happened. Together with diff's habit of merging adjacent hunks into bigger hunks, this means that potentially problematic merges are more likely to simply fail – which is a _good_ thing...
CVS requires _no context_, and though this can be convenient for `obvious' cases, by the time that you realize something is non-obvious, it's already too late, CVS has already applied a bunch of possibly incorrect changes, intermixed with non-applied changes using context markers.
This document was translated from LATEX by HEVEA.