7

The advantages of using git-svn over git are obvious(svn compatibility), but what are the advantages of git over git-svn?

Mike
  • 23,892
  • 18
  • 70
  • 90
  • 5
    Access to svn is not an "advantage of git-svn over git". The purpose of git-svn is to give you the advantages of git over svn. You cannot usefully use git-svn without using git. – William Pursell Feb 18 '10 at 06:23

2 Answers2

5

It simply means you have one less VCS to manage in your development chain (svn).
In term of administration:

  • you are left with distributed repositories managed by Git, each one autonomous with their complete history
  • you do not have to maintain a connection to a central SVN repo.
  • you can organize your backups differently (pushing your data to a remote backup bare repo, or exporting your Git repo through git bundle)

And of course you can manage all the advantages of Git over SVN.

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
3

git-svn and git share the same functionality while working locally. The difference appears when one sends or receives modifications from remote repository.

  1. Push vs. dcommit.

    Why git-svn needs this separate dcommit command?

    Because Subversion repository behaves differently from remote Git repository: SVN always tries to merge incoming changes on directories level. If one modifies a file that was modified concurrently by another user, SVN rejects incoming modifications with out-of-date error. Otherwise commit/dcommit passes.

    In opposite to that, Git push returns out-of-date error when one modifies the same branch/tag, no matter what files were touched.

    As result, git-svn dcommit has to make sure that the version it just committed is the same as it expects (some directories could be auto-merged during dcommit). That means, git-svn always pulls/fetches back the changes it just sent to SVN repository.

  2. File ignores.

    When one ignores certain files in a working tree and commits this modification, there're no means to send this modification with git-svn dcommit. So, there's no way to share ignores with other SVN repository users.

  3. Git attributes.

    Both Subversion and Git have certain metadata associated with files and directories. Similar to .gitignore there's no way to share .gitattributes with co-workers.

  4. Merge commits.

    Finally, when one tries to dcommit a merge commit there's a chance that certain commits won't be sent to SVN repository at all. That happens when all the commits of a merged branch were not dcommitted yet to SVN repository.

Most of these git-svn problems are hard or even impossible to fix. You may consider SubGit — a server-side alternative to git-svn that fixes most of them.

For more details see SubGit documentation and SubGit vs. git-svn comparison.

vadishev
  • 2,979
  • 20
  • 28