4 ms·

SVN is very easy to use compared to Git (or Mercurial etc.). This allows my team to provide version control for teams who aren't very technically skilled but wh

SVN is very easy to use compared to Git (or Mercurial etc.). This allows my team to provide version control for teams who aren't very technically skilled but who are nevertheless producing content that will appear on our website somewhere (e.g. static content).

dguaraglia 15y ago
Really? I used Subversion for over 4 years and suffered through the regular merge issues, connectivity issues ("huh, can't commit because I'm not connected"), line ending issues, you name the problem I had it. Two days into using Mercurial I felt more confident with it than I had ever felt with Subversion. I could branch code without having to work with the server, I could commit on my own machine and later push changes... and the merges just worked. No praying for ten minutes, no stupid CR/LF vs. CR errors, nothing. I guess you'd have a point about easy of use if you count on the excellent TortoiseSVN. In the beginning Mercurial and Git didn't have anything as nice as that.
- arctangent 15y ago
  The kinds of people we provide SVN for have almost no technical skills whatsoever. You could spend a month trying to explain what a merge was and they wouldn't understand. But they do need to produce content (which they'd like to be version controlled) that they expect my team to put up on our website. From our point of view, SVN is a near-perfect solution: explain how to check $SOMETHING out and how to check it back in when you've amended it (using the excellent TortoiseSVN). Once they've checked their work back in they email our team email address and one of us runs SVN UP on the relevant server, and we're done.
- Aga 15y ago
  How are you safe from CR/LF vs. CR errors in Mercurial? I'm curious, because at least Git does not protect you from CRLF-problems out of the box. All the committers must have right settings (autocrlf=input for unix and true for Windows). In case of a central repository, you probably should have a protection hook in case someones settings get changed anyways.

dguaraglia 15y ago

Really? I used Subversion for over 4 years and suffered through the regular merge issues, connectivity issues ("huh, can't commit because I'm not connected"), line ending issues, you name the problem I had it. Two days into using Mercurial I felt more confident with it than I had ever felt with Subversion. I could branch code without having to work with the server, I could commit on my own machine and later push changes... and the merges just worked. No praying for ten minutes, no stupid CR/LF vs. CR errors, nothing. I guess you'd have a point about easy of use if you count on the excellent TortoiseSVN. In the beginning Mercurial and Git didn't have anything as nice as that.

arctangent 15y ago
The kinds of people we provide SVN for have almost no technical skills whatsoever. You could spend a month trying to explain what a merge was and they wouldn't understand. But they do need to produce content (which they'd like to be version controlled) that they expect my team to put up on our website. From our point of view, SVN is a near-perfect solution: explain how to check $SOMETHING out and how to check it back in when you've amended it (using the excellent TortoiseSVN). Once they've checked their work back in they email our team email address and one of us runs SVN UP on the relevant server, and we're done.
Aga 15y ago
How are you safe from CR/LF vs. CR errors in Mercurial? I'm curious, because at least Git does not protect you from CRLF-problems out of the box. All the committers must have right settings (autocrlf=input for unix and true for Windows). In case of a central repository, you probably should have a protection hook in case someones settings get changed anyways.