Well, actually git-svn is really useful when you work in an environment where SVN is used as VCS.
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."
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