Update 2017-10-31: The developers of Subversion were a bit surprised, but it turned out to be a genuine bug. The bug has been fixed the same day.
The TeX Live project uses Subversion as its main repository. Reasons for that there are many, see my blog post on svn and git. But today I realized that subversion is broken, badly broken, because one can easily end up with inconsistent version numbers.
To understand why this is a problem, I restart from the already linked blog: “…Our packages have revision numbers based on the latest change revision of all the contained files. Since subversion has a linear history and central repository, this guarantees that – in contrast to version numbers provided by authors – the revision numbers are strictly increasing…”.
Well, it turned out that this assumption was wrong. Because it is easy to trick subversion to have wrong revision numbers for files. Consider the following flow:
- revision A: file xxx is changed
- revision A+n: file xxx is changed again
- revision A+n+m: file xxx is changed back to the state at revision A
In our case we have files listing other packages, and they are getting moved around at times. In this case one package was moved from one collection to another and back.
Now, if user A does svn up between revision A+n and A+n+m, then the final revision in his checkout of file xxx will be A+n+m. But a user B that does NOT do svn up between A+n and A+n+m will end up with a final revision of A for file xxx in his checkout. And boooom, revisions are different, although the files are in sync with the server.
I cannot grasp what the developers of subversion thought about here, but I consider it deeply broken by design. One more reason the rewrite all our distribution scripts to work with git instead of subversion.