>Situations now flagged as conflicts include deletions of locally modified files, and incoming edits to locally deleted files. Files and directories which are victims of a tree conflict cannot be committed before the conflict is marked resolved.

Wow - finally! This is great. We've had to handle these edge cases during merges (greatly slowing our scripts) for a long time. Hopefully this will give us significant speed improvements which should help with one of the minor irritants of our users.

Seriously .. don't put the enterprisey stigma on it. It does not deserve that.

What am I missing?

I've read all the "Git is AWESOME" posts. If I switched to git, it would be exactly the same. It wouldn't solve any problem for my use case that svn doesn't.

Seriously unimpressed with your comment to be honest.

Either make a valid argument as to what I don't understand about version control, or retract it.

Of course, any distributed VCS would probably fit that description... I found mercurial to be nice as well, and I used it happily for a couple projects. The primary reason for switching to git was to become familiar with another tool.

(Unless you never use svn update, you do branch and merge. You just don't have any control over how it works.)

Git automates patchset management, not merging of rapidly diverging branches of the -same- code. With or without git, independent developers working on a set of patches for the same code will introduce genuine implementation conflicts that can not be merged without independent communication.

If, however, you should find yourself in this remarkably inefficient situation (ie, a commit war over simultaneously modified files), I recommend:

1) Speak to the other developer.

2) svn diff >saved.diff && svn up OR tar -cf ../svn.bak.tar . && svn up

Give me an example of when you "wouldn't like its auto-merge".

Anyway, I am glad you like svn. But it is probably due to some reason other than svn's technical merits like, "at least it doesn't have all these Ruby fanbois." That is totally understandable, ignornat fanboi-ing is VERY off-putting. (To be fair, I started using Git loooong before it was popular. So I don't consider myself a fanboi.)

Also, you don't learn anything new by sticking with what you already know. Perhaps it is worth expanding your horizions. Maybe try creating a branch in svn and go from there -- you might like it.

Why can't you just "svn update Foo" ? Then you don't have to deal with the changes to Bar :/ I don't really see what the issue is. Are you often working on exactly the same files as other developers, and not co-ordinating what you're doing?

>> "Anyway, I am glad you like svn. But it is probably due to some reason other than svn's technical merits..."

I like it, because it solves my use case perfectly. I'm not quite sure you understand that.

I'm not one of these people that love technical solutions for the sake of being technical.

You stated that anyone using subversion must not understand revision control. Which is an idiotic comment.

I detest this pompous high and mighty tools based attitude. Does anyone not using lisp not understand programming? Anyone not using ruby on rails not understand how to build webapps?

I'm actually very open minded. When I have problems with subversion, I'll likely try git if it fits my use case at the time. At the moment, it doesn't.

But you said above that you don't want to understand version control; you said you just want to use it. This does not disprove my statement.

We use SVN and it does the job just fine. In fact, we are still stuck on 1.4 so we track merges ourselves which isn't really a big deal.