Marking Changed Text in Journal Revisions
I recently went on a bit of Twitter rage after reviewing the revision of a 40-page manuscript, where the authors in no way indicated in the manuscript what they had actually changed.
In the ensuing Twitter conversation, some people have asked me for how I normally mark up changed text in revisions. What I do is really low-tech: I simply use a different color for new or importantly changed text.

I find this approach to be very easy to do and less visually jarring than a full change log, while still making abundantly clear what we have updated in a manuscript.
An appropriately low-effort way to do this is to create specific LaTeX markup for changed text, like so (requires the color package to be imported):
\newcommand{\rev}[1]{\textcolor{blue}{#1}}
You can then simply demark your changes and additions while writing:
Our approach outperforms all other approaches by 100%.
\rev{My father says so as well.}
Hence, the world will be changed after this manuscript is accepted.
This has the advantage that you don’t have to cumbersomely remove the markup for the final version — you can simply set the text color for \rev back to black and re-compile.
This approach works well for text and text-like content (e.g., table values), but breaks down for figures. For these, I use another custom markup that draws blue lines above and beyond a changed figure (see also the right-hand side of the screenshot above). The markup to generate these frames is a custom environment based on the mdframed and ntheorem packages, and can be used like this:
% in preamble
\usepackage{mdframed}
\usepackage{ntheorem}
\theoremstyle{nonumberplain}
\newmdtheoremenv[%
linecolor=blue,
linewidth=2pt,
rightline=false,
leftline=false]{figrev}{}%
% ...
%% in document
\begin{figrev}
\includegraphics[width=\linewidth]{img/litsearch.pdf}
\end{figrev}
The above code should be fairly self-explanatory and easy to adapt in case you want to change how your markup looks. Sadly, these tags you’ll actually have to manually remove before handing in your final camera-ready version (or you combine it with ifthen, which I don’t want to get into here).