All subsystem maintainers had their own way of working with this. Some used svn, some used bespoke scripts.
The main reason for creating bk and git was that none of the existing version control systems matched the workflow of sending patches via a mailing list. This is quite clearly reflected in the design of git, a tool for quickly wiping and recreating a whole project directory.
Linux development history was imported to git, and you can follow it back in time since long before the introduction of git, so in that sense some form of version control can be said to have existed.
My understanding is that even during the BK years, some maintainers refused to use it and would continue to use tarballs + patches.
Another weird one is a distributed version control system over UUCP [1]. Although not distributed in the modern sense
[1] O'Donovan, Brian, and Jane B. Grimson. "A distributed version control system for wide area networks." Software Engineering Journal 5.5 (1990): 255-262.
A strange case I've run across from the SCCS and RCS era is Plan 9. The history of the Plan 9 kernel is stored as ed scripts[0], which produce revisions per file, essentially like ad hoc SCCS deltas. I'm not sure if it was assembled as such after the fact or recorded like that all along. That method seems to have only been used for the kernel and the rest (such as the libraries) was snapshotted daily on a file server starting in 2002.
[0]: https://9p.io/sources/extra/9hist/README (To look around, just pop off README.)