Because of the way SVN expects on-server merges, you may see some strange looking merge history when working with someone using Subversion.
I'm genuinely curious: what use case justifies this? Correct and clean merges and history are a major selling point of Git. Is this for people on Git-using projects who can't be bothered to learn a new VCS?
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!
Now if only they added a possibility to clone a repository from GitHub to BitBucket (or the other way around) via the web interface, that would be just perfect...
Yeah - but I meant something easier to use... Like registering on both services and having a choice of "fork on github" and "fork on bitbucket" on every project (and on both services).
Both sites have APIs, it could be done though a third-party. I've thought about giving it a shot a couple times, but I have more important things on my plate.
I'm genuinely curious: what use case justifies this? Correct and clean merges and history are a major selling point of Git. Is this for people on Git-using projects who can't be bothered to learn a new VCS?