drawbacks to svn server + git-svn vs git server?

Hello. My group is currently using subversion on our version control server, but would like to move to git as a client. We are considering using git-svn, to avoid revalidating the server software. My question is, are there any major disadvantages to using git-svn versus git? I know that the git repository would be smaller. I'm more concerned about possible svn repository corruption, performance when pushing large merges back to svn, and any gotchas you might have encountered.
Any advice would be greatly appreciated.
Thanks,
Ed

View this message in context: http://www.nabble.com/drawbacks-to-svn-server-%2B-git-svn-vs-git-server--tp25994334p25994334.html
Sent from the git mailing list archive at Nabble.com.

Something that come to mind immediately is that you'll loose merge information as Subversion has linear history. I understand that recent Subversion versions have added some information about merges but I don't think git-svn handles this (I don't even know if it makes sense or not:).

If you have a single integrator you'll also loose the author name. Keep in mind also that git-svn is slower to get new commits from the upstream repository.

I've used git-svn for a while now without any trouble. And I can say that I won't move back to using an svn client.

Pascal.

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|    http://www.obry.net  -  http://v2p.fr.eu.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver keys.gnupg.net --recv-key F949BD3B

AFAIK, SVN remembers what changesets have been merged and what are not (on per file basis). So, it is more like cherry-pick with some automatic tracking than git merge, and stored separately for each file in the repo. So, I do not think it is easy to map svn merge concept to git one...

Inability to do merges mean that you have to track what changes what branch by hands, which is very inconvenient if you have a few long living branches.

Another long standing issue with git-svn was automatic end-of-line conversion. It did not work with git-svn and the last time I heard about it, it was disabled for repository created by git-svn. Probably, it may not difficult to correct, but no one has looked at that closely....

Right... And if everyone has the right to commit then git-svn will automatically rebase your changes during 'dcommit' on top of changes made by other people, which means that you put into the repository a different state than one you have actually tested.

Dmitry

Hi,

I recently migrated from svn to git as well, but I've abandoned the svn server altogether.
What I noticed is that the merges do not show up properly when you look at the svn repo with git. Obviously because svn doesn't track that information. I assume that such a problem would continue if you continued using the svn server.
Personally, i would recommend migrating to git altogether, it isn't actually that difficult. The only issue I had was fixing up the merges. Sorry I can't be of more help, I'm just letting you know what issues I faced with svn.

Good luck,
Tim.

View this message in context: http://www.nabble.com/drawbacks-to-svn-server-%2B-git-svn-vs-git-server--tp25994334p26093326.html
Sent from the git mailing list archive at Nabble.com.

One rather big drawback is that "git svn dcommit" has to do some history-rewritting. In other words, if you have a local commit A in your repository, and send it to the SVN server with "git svn dcommit", then A is rewritten into A' (same tree content, but different commit message at least, and maybe other details I'm not aware of). If you use git-svn as a "better SVN client", it's not a problem, but if you want to really use the Git part of git-svn, then this history rewritting will break the local branches that reference your A.

Matthieu Moy
http://www-verimag.imag.fr/~moy/