About the same time, I looked to see if there was any research on the effectiveness of a version control system like git vs. other methods of versioning (like VMS-style numbered versions, or backup/snapshotted file systems with a temporal browser).
I found nothing.
FWIW, "git leaderboard" is trivially gamed. Not only with pointless auto-commits, but some people commit every few lines while others commit only when things are in a good shape. What you ended up doing was introducing the same sort of resentment as factory workers under Taylorism and observations from the time-and-motion man.
Had our schools taught more about the history of labor rights and struggles, and perhaps less of the success of industrial oligarchs, then perhaps you would have been more likely to expect that resentment and not tried it in the first place.
Eh, there were no rewards, so no real incentive to win. The idea was just more to get the act of committing their code into their minds. Like "oh hey, everyone can see I'm at zero, maybe I should commit my work".
This was something I tried after months of poking people to commit their work.
I'd put together a whole training on what git is and why we should be using it. It came up every weekly meeting. I was grasping at straws.
Then no real inventive to lose, so no real incentive to switch, so no real incentive to care about a scoreboard, while making those who might test the waters subject to possible public ridicule.
What do you think the advantage is to 1) using a version control system, and 2) using git, in the aughts?
Version control systems have been around since at least the 1970s (dating from SCCS), so 30 years before your experience. My group was using RCS in 1993. Which means the people you were trying to convince almost certainly know about the concept and possibility before you tried to persuade them.
Frequent backups of a shared file system is a form of versioning. VMS-file filenames.txt;001 is a form of versioning. Moving projects into new directories is a form of versioning. None of them require any special training to get started, and the latter two let you use any normal tools to view and compare different versions of the file.
Some places had conventions about who was allowed to modify a file, while the git model is that anyone can modify anything.
Which means there are clear negatives to switching to git, especially for an organization which has been using another means of versioning.
What did you do to minimize those negatives? What did you do to provide transition system so some people could use the old system and others the new? Why start with git, and not something like RCS/CVS which was structurally more aligned with the centralized model they were used to?
> while making those who might test the waters subject to possible public ridicule.
I mean… No? A board basically showing that you're actually doing your job isn't going to get you ridiculed…? If it is, the person ridiculing you obviously is a moron.
> using git, in the aughts
Even in the late aughts, git was the obvious successor. Anyone who had spent any amount of time with it knew it simple and powerful.
We had our core application from which everything was forked in SVN. SVN was always a nightmare. Conflict resolution in SVN was basically just not going to happen. Blow the repo up and start over. SVN was never a usable piece of software.
This was the very first thing I moved to git, and it was a godsend.
We'd tried SVN for some of our other larger projects and it would always end up in some dumb broken state we couldn't get out of. I remember BerkleyDB corruption being like the name of the game.
> Why start with git, and not something like RCS/CVS which was structurally more aligned with the centralized model they were used to?
The way I was trying to get them to use git was basically no different from how they were already doing their work.
The way we worked there was only ever one developer on a project at a time. I basically just `git init && git add .` 'd the existing directories on the SMB share. The developers would continue to work on the existing SMB share as usual and all I was asking was just commit their work _on occasion_. I wasn't asking for branching or PRs or even sensibly structured commits. Let's just have some history to start with. Anything would have been better than the nothing we had going on.
The big incentives for the developers were:
1. Having an actual history of changes.
- While we had nightly backups, they only went back maybe a month at most. Something fell out of that time range, it's gone forever. Want to see how something worked six months ago? Too bad.
- Pulling backups was not an automated process. We had to contact our grumpy IT guy who lived in Juneau Alaska and worked Alaskan hours. Depending on when the problem happened, you simply had to wait for him to wake up sometimes. You almost certainly wouldn't contact him just to casually see how something used to work.
I'm more than certain our need for some sort of solution was obvious to everyone who worked there.
2. Having just any sort of history of who changed what, and ideally why.
It really was the wild west. Anyone could open any folder on the smb server and mess with anything. Then that change was liable to end up on production were it not caught in testing. This was a non-stop issue. Who broke X? No idea.
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.
I found nothing.
FWIW, "git leaderboard" is trivially gamed. Not only with pointless auto-commits, but some people commit every few lines while others commit only when things are in a good shape. What you ended up doing was introducing the same sort of resentment as factory workers under Taylorism and observations from the time-and-motion man.
Had our schools taught more about the history of labor rights and struggles, and perhaps less of the success of industrial oligarchs, then perhaps you would have been more likely to expect that resentment and not tried it in the first place.