When a changeset wants to modify a region of a file and that region has been independently modified since the changeset was created, this modification (patch hunk) cannot be applied. The conflicting patch hunks are saved in a .rej file named after the target file. Resolving the conflict often means doing some editing so the rejected hunks can be applied.
The rejected patch hunks correspond to the rejected local changes for tla update, and to the rejected changes in the archive for tla replay. See ReplayVsUpdate.
A good habit is to add the rule "unrecognized \.rej$" to the file {arch}/=tagging-method, so that tla tree-lint and all commands calling tree-lint warn you when you have *.rej files in your working directory. (See this discussion for details.)
MilesBader posted a message to gnu-arch-users mailing list explaining how to apply *.rej files (patch rejects) using GNU Emacs or XEmacs:
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. So for instance a typical strategy I'll use is:
Visit the .rej file in emacs; this will automatically be in diff-mode
Make the buffer writable using "C-x C-q" 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.
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 (the buffer need not be writable from step (2) to do this!).
Use C-c C-a to try to apply the hunk (Note that this shouldn't work, because hunks in the .rej files are here because they have been rejected. But it's good to try !!) ; if application succeeds, delete the hunk from the .rej file with "M-k" (the .rej buffer must be writable to do this), and go on to next hunk, otherwise:
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.
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 (4).
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 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.
Non-Emacs users can convert .rej files into unified diffs using filterdiff, from the patchutils package. Typical invocation: filterdiff -v --format=unified foo.c.rej
For the specific case of conflicts in GNU-style ChangeLog files, the tla-fix-changelog-conflicts command in the tla-tools package may be useful.