Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I have a confession to make.

At my first job (small shop with three devs) they were using VSS and it was so much of a diasaster that I took it upon myself to prepare a sizable document on why do we need to move off of VSS to something like SVN. Manager's response was something along the lines of "I don't trust those fancy merge algorithms, unlock-modify-lock is the way to go". I couldn't convince him otherwise, he wouldn't even agree for a itsy-bitsy pilot project to test the waters.

Having exhausted all my options, I did two things. First, I "Got Latest" of the entire repository. Second, I wrote a smallish script that would overwrite a single random byte in a random number of files inside the VSS database directory and scheduled it to run overnight. Of course it would self-destruct upon completion, so that no traces were left.

The next morning, VSS was on it's knees and nothing could be done. Turned out we had no backups.

And this is how we "migrated" to SVN.



We migrated SVN exactly the same way. Except I didn't write a corruption script. Turns out VSS was capable of corrupting itself beyond repair with no help from anyone! Or wait, did you work in my office?


I'm tempted to try this with our TFS setup [1] (VSS in all but name [2] with lots of "features" unrelated to version control)...

1: Yes, I know that TFS supports git repositories. But I have the same issue: Convincing management that this might be a good idea.

2: Actually I consider TFS's source control part worse than VSS. While VSS was a hack, TFS is sold as 'enterprise' software. And it's unbelievably bad (again, only talking about the source control part and leaving out all the other things it can do. Maybe some are less half-assed than the source control part is?). Given the choice I'd pick CVS over TFS.


TFS using GIT isn't too bad. You then get GIT, with the project management features of TFS.


TFS keeps all the crap inside an SQL Server database, so it might be a bit harder to perfom the "trick".


Well that was an option. An other one would have been to point out that svn does support lock-modify-unlock so that was no issue.


I don't think that the manager's actual reason for support for lock-modify-write. I think he was just opposed to changing anything in the realm of source control and this was just a convenient rationalization.


Today's example of this would be TFS or Sharepoint.




Consider applying for YC's Fall 2026 batch! Applications are open till July 27.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: