I work on source code from two separate SVN
repositories. One of them is geographically remote. Working with the remote server is slow for ‘log’, ‘diff -r’, ‘blame’, etc. Due to my interest in distributed version control, and my desire for faster repository access, I decided to try git and git-svn. Doing ‘log’, ‘diff’, etc. with a local git repo is much faster, but on the whole, working in a git repo created with git-svn has been difficult and unrewarding. Perhaps it would be easier if others at my company were using git-svn and we could share ideas. Working with git and git-svn requires learning a new workflow, and I haven’t yet reached enlightenment.
Challenges with Git:
- The Git Wiki is often out-of-date and/or incomplete (submodule support, for example).
- No Nautilus, Konquerer, or Windows Explorer integration.
- No KDevelop itegration.
- git-gui should:
- let me double-click on files listed in either “Staged Changes” or “Unstaged Changes” to edit the file. Or let me right-click and choose an “edit” option.
- Let me use an external diff program such as meld or kdiff3. git-gui should let me set this up and use it. qgit has an external diff option (defaults to kompare), but it doesn’t use the working copy on the right hand side, so it’s not possible to use the diff tool to change the working copy file.
Challenges with Git-SVN: (More complicated to use than Subversion)
- Two stage commit instead of single stage. ‘git commit’, ‘git-svn dcommit’
- Error messages are cryptic, so I don’t know how to resolve the errors.
- git-svn rebase doesn’t merge changes from upstream Subversion server into my working copy, and git-svn doesn’t tell me what workflow I should be using. So I ran git-svn fetch to pull upstream Subversion changes. Then I ran git-gui and chose Merge->Local. It told me something helpful. “You are in the middle of a change. File X is modified. You should complete the current commit before starting the merge. Doing so will help you abort a failed merge, should the need arise.” “git-svn rebase” should have told me
the same thing.
Reasons to continue with Subversion:
- Workflow is easier, less complex — perhaps because I’m used to it.
- Windows Explorer integration via TortiseSVN.
- IDE integration. Nearly every IDE supports or has a pluging for Subversion.
- svnmerge.py gives me cherry-picking support (between branches within the same repository)
- svnmerge.py remembers merges, so I don’t have to resolve the same
conflicts twice. - I don’t need disconnected operation in my workplace.
I hope that in a year, Git, git-svn and developer tool integration will be more mature and thus rewarding to use. With the rapid development I see happening, it wouldn’t be surprising.
I will continue to use git-svn. It gives me the speed I need for working with log history, annotate and diff.
Update: I’ve come across Git for Computer Scientists, and seeing the pretty graphs leads me to believe that working with git requires an understanding of how git works.