Yes. The use case is for organizations who have a lot of developers, some of whom want to (or demand to) continue using Subversion for their VCS needs. This can include people who don't really want to use VCS at all, but have become comfortable with some tool like TortoiseSVN or the like. We would obviously prefer everyone use Git, but we want to provide a bridge to help teams get there.
Also, you still have correct and clean merges, but since it's somewhat difficult for me to figure out what your last base version was when an svn client commits, it uses the latest version number of any submitted file as one parent and the current head as the other for anything that needs to merge, so the history may have more parents in it than are strictly necessary. If the merge does not happen cleanly, the server will reject the merge and you have to update and fix locally, like normal SVN. However, since the concept is new, I wanted to leave as much information in the Git history as possible, thus the extra parentage information.
Yeah, mixed-rev working copies are a huge pain in the rear. They make a lot of problems for conversion tools when you commit from them, I can't imagine writing a server to deal with them even remotely sanely.
What does the Git DAG end up looking like when a commit comes in from a mixed-rev WC? Do you have any examples I can see?
Great stuff. I know of many people who look at the GitHub community and UX with great envy but have feared to make the plunge because let's face it, there's just no killer GUI clients for Git yet. Having Subversion support is the gateway drug for those folks. Looking forward to see how this evolves. Congrats!
Also, you still have correct and clean merges, but since it's somewhat difficult for me to figure out what your last base version was when an svn client commits, it uses the latest version number of any submitted file as one parent and the current head as the other for anything that needs to merge, so the history may have more parents in it than are strictly necessary. If the merge does not happen cleanly, the server will reject the merge and you have to update and fix locally, like normal SVN. However, since the concept is new, I wanted to leave as much information in the Git history as possible, thus the extra parentage information.