In general, the amount of bullshit you'll have to deal with from a piece of software is inversely proportional to the number of users of that software. And the number of users of git-svn is much lower than both SVN's and Git's.
But you didn't try, now, did you? You state you used SVN twice only and the first time was very brief.
So..
- The claim is useless (your experience in general might not be relevant here)
- The 'inversely proportional' line is a gut feeling, not helping - and the whole comment here was a copy/paste from your blog comment.
Several people point out that there might've been a good solution and you cross-post 'Yeah.. I don't believe that. And let me hide my personal belief behind some math related statements' and even refer to that answer of yours when _even more people_ tell you that you should've tried git-svn (again on the blog, replying with 'see what I replied to X')?
I'm confused. Why are you so confident that you didn't miss out an easy solution?
1. Edit some files
2. start git gui and commit
3. repeat 1+2 as many times as you want
4. git svn dcommit
5. all local commits will now be committed to the SVN repo
I've been doing this for almost three years now and haven't had any major problems yet.
Except for: Merging. Since SVN 1.5 (or so) merging in SVN got less painful because from then on when merging, SVN tracks which revisions have already merged from one branch to the other.
AFAIK it does so by saving the merged revision ranges into the svn:externals as meta data which can then be used for the next merge operation to prevent changesets to be merged twice into the same branch.
However, when you merge with git-svn this information will not be recorded, so the next person merging with SVN will probably run into problems.
Solutions:
a. you don't merge with git-svn
b. anyone merging with SVN explicitly tells SVN which exact revisions to merge
You can still use local branches of course and as long as you only merge from one local branch to the other with Git, there won't be any problems.
At my work place we luckily pretty much only have trunk and very, very short-lived branches, so this isn't an issue for me.
A correction, while the fact that SVN creates a copy of the entire code, when you create a branch, it isn't as horrible as it sounds, from the SVN documentation:
"When you copy a directory, you don't need to worry about the repository growing huge—Subversion doesn't actually duplicate any data. Instead, it creates a new directory entry that points to an existing tree. If you're an experienced Unix user, you'll recognize this as the same concept behind a hard link. As further changes are made to files and directories beneath the copied directory, Subversion continues to employ this hard link concept where it can. It duplicates data only when it is necessary to disambiguate different versions of objects."
( http://svnbook.red-bean.com/en/1.5/svn.branchmerge.using.htm... )
That being said, the day my company will finally switch to Git will by a happy day... :D
On the whole, I find git-svn much nicer to work with than raw SVN. I can have local branches for work in progress, merge/rebase and with/onto trunk with ease, queue up multiple commits before pushing, work offline, etc. Using plain SVN, by comparison, feels like driving blindfolded in reverse with the handbrake on. CVS is like additionally having your head in a bucket of water.