Versioning Failure

It was many years ago, when I first was introduced to the marvels of a Version Control System when working as a developer for an Enterprise Support Platform.
My customer was using the PVCS for release management - I had never heard of automated versioning before.

I love automation, and I loved the things the PVCS could do for me.
However, I quickly grew weary that after pretty much every couple lines of code, I had to do the following:

1. Add modified files to the repo
2. Do a diff to verify the changes
3. Commit the changes
4. Publish to baseline

Whenever I run a manual activity multiple times, my first thought is "Automate this". So this is what I did.
It was very easy to automate. Always the same commands, always in the same sequence - so I just scripted it!

Then came this glorious Friday. It was my last day of work before vacation.
Everyone else had already left the office.
I wanted to complete this one last task. It was trivial, one single line of code.
So I implemented the change, did my tests, ran my script and took off.

On Monday morning, I got a phone call "What did you do to our baseline? EVERYTHING is gone!"
What?

Took a while to figure out my "push script" went rampant and committed every single item in the project as zero-byte file.
While I was on vacation, it took the rest of the team half a day's work to clean out the entire mess I had unwittingly created.

Probably I took this one harder than the team, but here's
My lesson:
I now understand why version control software does not provide "one-step push" for changes. No automation can understand what the intention of your change was.

Not everything that can be automated should be automated.
Keeping the "brain-in-the-loop" is often the only way to eliminate accidents.

And this is why I no longer believe in "full automation".