I was using SVN for my personal projects 10+ years ago. It's crazy to think that some companies may not be using source control even today...

I used to work with SVN in a group of 3 developers and several branches (test, staging, master) and it was pretty messy.

When I read the original comment about bug fixes disappearing, it reminded me of merging test onto stable by hand, not knowing what was "the good code" and having to ask, research, etc. It was messy and some times we got regressions.

We called this thing, a bug fix got "merged away".

Nowadays with Git, feature branches, better test coverage, continuous integration; things have got much better.

You guys must not work in electronics.

I worked in electronics 30 years ago and we had revision control.

They're definitely out there.

Even in places that think they do, it seems pretty common to have an additional codebase in the database without any real version control.

I'd like to know how problems like this correlate to data breaches.

I worked for a client years ago, Dropbox was source control. It wasn't as bad as none, but you lost changes at the 30 day mark.

Were the (technical) employees happy about it?

I.e. was it just a crazy requirement handed down, or did they not know better?

I just can't imagine it even for solo development, nevermind collaborative work! "Agh. We must have had a merge conflict, damn, the core part of my work is gone... Let me see if I have a recent copy... Oop, no, I don't, because I've run out of disk space from all these clone backups."

FWIW, I use git inside Dropbox for my personal solo projects. I don't want to have to use commits and git's remote syncing mechanisms to share in-progress code between my desktop at home and my laptop. I want to be able to pick up exactly where I was on the other machine, including my git staging area and local unstaged changes. It works perfectly for this.

I do occasionally get Dropbox-level merge conflicts for tmp editor/IDE files, but I can't recall getting any for source files.

So, neat trick: "git clone" your local Dropbox copy somewhere, and you get the benefits of "commit" and "push", but it's local; and then your remote is synced via Dropbox :)

> neat trick: ... and you get the benefits of "commit" and "push"

GP seems to be deliberately avoiding commands relating to remote management, such as push.

I use a similar setup. I use spideroak hive since its 'zero knowledge', I don't however sync any binary or IDE directories. This allows me to have the source files and git repos synced, but still keep somewhat independent set ups.

just so you know, git on dropbox is not a great idea in a team. solo it should be fine but you are probably better off using bitbucket for free.

All projects were single developer. It was a burn and churn environment. Contractors from all over the world, share a folder from the root, they work in it, when they completed it, the folder was unshared and they were paid.

It worked OK for that purpose. And I still have dropbox mainly for that reason. My source code is always local. Everything goes into TFS, but the local is backed up to dropbox.