An alternative to branching in some cases, especially for short lived branches like for journal submission, is using patch queues. Mercurial has
mq. I believe Git has similar things, but I'm not a git user.
As the question says:
When I used different branches for different journal submissions,
I found myself working only on the "latest" branch anyway, since I can
anyway only submit one version per time, and, if it is rejected, will
not continue to work on that particular version at a later time.
I have had similar experiences when using different (named) branches for submission to different journals. The problem is that one ends up having dead branches which correspond to journals the paper was rejected from, or perhaps journals you never ended up applying to. These live forever in history, which is annoying and sub-optimal.
The advantage of using patches, at least with
mq, is that one can maintain multiple patch queues, each of these can be managed as a distinct mercurial repository, and they do not become part of the main repository's history unless you want them to, though of course you can push them to remote since they are regular repositories. Also, one can use them with general non-vcs tools like
quilt, which is occasionally useful.
However, when applied, these patch queues are a bona-fide part of a mercurial repository, and can be treated as (anonymous) branches. So, suppose one has two patch queues
Q2. Then if wants to work with both versions simultaneously, one can make a clone of the main repository, thus resulting in two identical copies of the repository. Then one can apply Q1 and Q2 to the copies, and then work with them as one would with regular branches, using mercurial's merge machinery and so forth.
Another use of patch queues which is very useful, and not specific to paper writing, is to queue up small changes in the queue till one is ready to commit them. I usually just stick everything in one patch, though one could divide the changes into multiple patches. Then, when one is ready to apply some or all of the changes, one can do
hg qref -X . # apply the patch as local changes, making the patch empty
hg qpop --keep-changes # pop the patch
This results in
a) the patch being applied as local changes to the working directory
b) the mercurial queue patch becoming empty and being removed (popped) from the repository.
Since the patch is now local changes to the working directory, we can easily commit what parts of it we please. When done one can resync the patch with
hg qpush --keep-changes # push the patch back onto the repository
hg qref # put the local changes back into the patch
hg ci --mq # commit the changed patch (to the mq repository)
Then the patch is recreated with the portions of the local changes that were not committed.
See the loosely related questions What's the Git approach to publish a patch queue? and git equivalent to hg mq?.