The main idea that makes distributed version control systems like git(1) work is to name versions not by increasing numbers, but by their content (including the history). However, that idea is completely independent of the underlying version control system. No one prevents me from computing recursively for every version of, say, an rcsfile(5), a hash of
In that way, I can identify a version (and the branch below it), even if it is on a different branch. One application is to couple two or more rcs files on different machines, where for each the work done locally is the main branch, whereas the work done remotely are on branches (unless they are "fast forwards"). Receiving an rcs file from a remote machine, all the versions not yet in the local rcs file can be added to the respective branches. There no is need to know in advance how many machines are involved; history just branches where appropriate. Merging these branches into the (local) main line can be done with rcsmerge(1), as usual.
The script I use to work decentralised with rcs files, some of which are part of a cvs(1) repository, is rcscjoin where rcsjoin base,v branch,v join produces an rcs file join,v that is base,v extended by those versions of branch,v not contained already.
Of course, locally queuing commits for a centralised version control system is a different option, in particular, if no conflicts are to be expected.