4 ms·

Sounds to me like you didn't know what you were doing with SVN. If I complain that Git caused some problems, Git users are likely (and often justified) to tell

Sounds to me like you didn't know what you were doing with SVN. If I complain that Git caused some problems, Git users are likely (and often justified) to tell me that I was using Git wrong. But it's rare that the same reasoning is extended towards SVN by many Git users. The worst I've had with SVN was a broken working copy, which is usually easily fixed. With Git, problems like that occur much more frequently. In the past 6 months I likely have completely wiped my local Git repository for a particular project alone more times than I've ever had to fix a broken SVN working copy. My experience is closer to the famous XKCD comic: https://xkcd.com/1597/ https://xkcd.com/1597/ Now, perhaps you could argue that I don't understand Git well enough, and I wouldn't necessarily argue against that. I think Git has a terrible and confusing UI compared against other distributed systems. (And the simplicity of SVN makes its UI good, I think.) As for performance, again, I use SVN with small projects, so performance hasn't been an issue. To be honest, I probably save time compared against Git from not having to type as much with SVN! And I don't branch in SVN because I don't want to, not because it's difficult or dangerous. Branching would provide no benefit in my case. If I wanted to branch, I'd switch to a distributed system. My experience talking to some Git people is that they often branch as a habit without considering what could be gained from branching.

baseballdork 8y ago
> My experience talking to some Git people is that they often branch as a habit without considering what could be gained from branching. There's just never a reason to not branch. It keeps ideas, efforts, tasks separated really nicely and has essentially no cost to doing so. It lets me have a completely different environment to try things out, wreck, and abandon things without ever touching the branches that are important. When I'm done, a simple merge brings it all in at once.
- btrettel 8y ago
  > It lets me have a completely different environment to try things out, wreck, and abandon things without ever touching the branches that are important. These are all completely valid reasons to branch. They also don't apply to most of my projects. And for the ones they do apply for, I use Git. My small projects tend to be relatively simple, and often contain a lot that's not code. (Some contain almost no code at all.) For example, I've had people recommend branching to keep track of different versions of the same paper they're writing. But this immediately struck me as a waste of time. I'll be submitting only one version of the paper. Why keep multiple internal versions? I am not convinced by the argument that I can have a branch for each person I ask to read the paper. Merging in the handwritten changes they provide me is not hard. Branching would just be extra work in this case. It can be nice to try different organizational structures sometimes, but I've found it easier to simply have a different TeX file in that case. (Or better yet, multiple TeX files for each part, and then a set of master TeX files that organize the paper differently.) If someone has a good argument for distributed version control in this use case, I'd be happy to hear it.
HelloNurse 8y ago
If network failures can leave working copies in pieces, in an unknown state, it isn't a matter of knowing what one's doing. Out of the box, Git and similar modern VCS systems offer better safety, and better auditing whenever something goes wrong.

baseballdork 8y ago

> My experience talking to some Git people is that they often branch as a habit without considering what could be gained from branching. There's just never a reason to not branch. It keeps ideas, efforts, tasks separated really nicely and has essentially no cost to doing so. It lets me have a completely different environment to try things out, wreck, and abandon things without ever touching the branches that are important. When I'm done, a simple merge brings it all in at once.

btrettel 8y ago
> It lets me have a completely different environment to try things out, wreck, and abandon things without ever touching the branches that are important. These are all completely valid reasons to branch. They also don't apply to most of my projects. And for the ones they do apply for, I use Git. My small projects tend to be relatively simple, and often contain a lot that's not code. (Some contain almost no code at all.) For example, I've had people recommend branching to keep track of different versions of the same paper they're writing. But this immediately struck me as a waste of time. I'll be submitting only one version of the paper. Why keep multiple internal versions? I am not convinced by the argument that I can have a branch for each person I ask to read the paper. Merging in the handwritten changes they provide me is not hard. Branching would just be extra work in this case. It can be nice to try different organizational structures sometimes, but I've found it easier to simply have a different TeX file in that case. (Or better yet, multiple TeX files for each part, and then a set of master TeX files that organize the paper differently.) If someone has a good argument for distributed version control in this use case, I'd be happy to hear it.

HelloNurse 8y ago

If network failures can leave working copies in pieces, in an unknown state, it isn't a matter of knowing what one's doing. Out of the box, Git and similar modern VCS systems offer better safety, and better auditing whenever something goes wrong.