> 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 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.
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.