FWIW, most of the collaborative projects I worked on in the 1990s were with CVS not SVN, so I never dealt with the BDB problems which I assuredly had with other

FWIW, most of the collaborative projects I worked on in the 1990s were with CVS not SVN, so I never dealt with the BDB problems which I assuredly had with other BDB-based tools on networked file systems. > Having an actual history of changes. Bootstrap by doing regular commits of the shared directory. Make that history visible and readily accessible. Start with it being a one-way directory->repo thing so nothing changes with the existing process. Set up a cron job or fs watcher to auto-commit at the temporal resolution you want. Start it as "just a personal tool to avoid bothering Juneau all the time." > Who broke X? No idea. Then the problem isn't that people don't want version control, it's they want the anonymity to write crappy code. There is a long history of 'it compiles so it's done' in programming, so you were exposing an existing fault line. I don't know how 'only ever one developer on a project at a time' works with 'Anyone could open any folder on the smb server and mess with anything', since the latter implies the former is not true. I have no suggestions about how to change those dynamics from the position you were in. For your "personal tool" also log the current/last-edited file owner? But you'll be guaranteed to be called a snooper if you do that.