[pjc50]

SVN is much easier to use for the standard corporate workflow of a group of people making commits to a project which mostly advances monotonically with continuous integration.

Edit: also in a Windows environment, svn copes slightly better than git. First project we tried it on had the worst possible environment, a mix of Windows and Linux systems. Line ending nightmares everywhere.

It also took a while to work out how to kill (with fast-forward) the spurious "merge commit" you get every time someone does a pull. You don't have that with svn, you just do the merging locally when you update and it doesn't generate a commit.

[brusch64]

I've been using Subversion since 10 years or so and I've changed completely to Git, so I've got experience with it.

For me Git was really a much needed upgrade to subversion. Working with branches (testing and production, we even have some repositories with multiple testing and production branches) are working like they are supposed to do. Changing commits (oops - I forgot to add one file) before pushing them to the repository for the other users is another big advantage. Working on multiple features in parallel - I couldn't do that with Subversion.

We've nearly completely eliminated the "handcrafted" local copies with multiple half finished features since changing to Git.

And if you want to use Git as a Subversion alternative you can use it in this mode too - altough you are missing out on some good new features.

I don't want to change back to Subversion.

The only disadvantage is that SourceTree (the GUI tool we are using) is a pretty lame duck in Windows. But the command line is excellent.

[TickleSteve]

So what problems exactly did you have with SVN?

branches are branches in svn or git... your process may not have been correct, but lets not blame the tools here..

modifying commits is a big no-no for me, so thats not a drawback at all, the fact that its not possible in svn is a win for svn.

[brusch64]

I really like modifying commits (as long as they are not pushed) - but I know that this is quite a controversial topic.

For one of our biggest projects branches in SVN didn't work at all.

We have multiple production, test and development branches and merge branches (features) from one branch to the other (development -> testing -> production). Sometimes we cherry pick a single commit to another branch.

In those days SVN wasn't so flexibel with branches as we wanted to (or we didn't understand it enough), so our workflow was much more rigid.

[screwt]

I'll second brusch64 here.

I used SVN for 7 or 8 years and then Git for the past 3, with about a year of overlap (on different repos).

To me, Git is vastly superior. I tend to use it in quite an "SVN-like" fashion - there's a single main trunk branch that we all share - but in terms of what I can do locally it blows SVN out of the water.

The difference is that Git makes things that are hard or impossible in SVN trivial. So for e.g. I create local branches all the time; I commit a bunch of small changes locally as I experiment with a fix, and then `merge --squash` to leave a clean history for others; merging fixes across different branches is easy and just works.

[TickleSteve]

Finally someone with a real advantage that a DVCS (not necessarily git) has over SVN.... local branches.

Most people just spout the same sheep-like line "git>svn" without being able to justify it!

[tempodox]

I concur. I would assume that git is the right tool for Linus's workflow, but whatever that is, it isn't mine. SVN does all I need and it has a friendly API and helpful documentation. In other words, the exact opposite of git.

[apk17]

SVN is a glorified backup - which is basically what you're saying.

The SVN UI is just horrid in other dimensions, mainly the "you can't do that at all" one.

[TickleSteve]

sorry... you come across as a git-sheep.

(getting down-voted for it, but someone has to say it)

[apk17]

I'm prepared to give you a lot of examples (which other people might value differently). From the unfortunate consequences of the 'branches are files (and therefore tags are easily mutable by default and surprisingly hard to pin down)' to usual "I just committed, why does 'svn log' not show that?", to git bisect, to git clean and the stubbornness with which svn refuses to even consider implementing that.

[pjc50]

TortoiseSVN provides the "clean" functionality if you want it.

[TickleSteve]

that sounds like process-issues... not SVN issues.

tags should not be committed to... end-of-story.

as for 'svn-log not showing commits'... I've never heard of that one in the last decade of using it... I'm genuinely interested in how that came about.