Hacker News new | past | comments | ask | show | jobs | submit login

We used SVN at my first job in 2006 and I had the exact opposite experience with it. I never fully understood what I was doing, nothing made rational sense, merges were an absolute nightmare, and somehow I would always ended up corrupting the repo and had to pull a nightly backup to get out of the broken state.

Git was a literal breath of fresh air in comparison. I fell in love hard and fast. Everything just made sense, even if our workflow using git am patches seems downright ancient these days. Friends at the time tried to sell me on hg, but I was in love.




I thought SVN was great, easy to use, and very intuitive, that is until you had any merge conflicts.

At the time, it worked very well for our small team, I imagine it would work less well for large teams on a single codebase.

I miss having a commit serial number.


I used kdiff3 and could never understand people complaining so much about SVN merges. Now I use kdiff3 in Git and it's fine, too. What isn't fine (though occasionally improving) is Git's UI and mess of termnology and concepts.


It's been a long time since I used it, I don't remember what I was using for diffs, but I suspect it was just whatever the default built in diff support was.

It occurs to me that many people these days use git with github exclusively, and have it configured to only allow commits via PR, and only allow either squash or rebase merges, it's kinda SVN with extra steps.


You have to sacrifice the serial number to get a distributed system. Well worth it IMO. But if you really wanted you could tag every commit on master with the next number (should be easy to do with a hook).




Consider applying for YC's Spring batch! Applications are open till Feb 11.

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

Search: