6

I'm tired of subversion, it keeps corrupting its own repository. As I was for a long time curios of git and always wanted to try it out, I've decided to give it a go and use git-svn. But reading through documentation I realized that you can't use much of git awesomeness with it. You can't use git-pull, it is not recommended to create local branches and there are tons of limitations. Looks like it is not much better than using subversion directly. Or is it? What pros and cons git-svn has over just plain svn?

PS. I'm sorry but I'm not asking you how to fix my subversion repository, I don't care that much. Deleting all .svn and checkout in the same directory overnight works fine. I just was wondering what benefits could git-svn bring to the table.

vava
  • 24,851
  • 11
  • 64
  • 79
  • 7
    You really shouldn't be getting subversion issues like that. The Subversion repository we manage at work is quite large (10,000+ files) and we've never had any corruption issues with it. Sounds more like a hardware issue, arbitrary corruptions should never happen. – Kieran Senior Aug 21 '09 at 08:02
  • 3
    I guess your repository is not used by non-programmers :) They can break anything. – vava Aug 21 '09 at 08:07
  • @vava: Non-programmers might be able to break their _working copy_ and lose tremendous amounts of work, but they definitely shouldn't be able to break the _repository_. Something seems to be fishy there and if I was you, I'd try to figure out how this happens before doing anything else. – sbi Aug 21 '09 at 09:06
  • Well, they do manage to break working copies of *others* through repository :) I don't know how they do it but it's not only me who experience problems. – vava Aug 21 '09 at 09:23
  • 1
    @vava: if the problem is working copy corruption through the repo, git-svn won't help. Git-svn uses the Subversion libs just as the Subversion server/client does, so if the bug is in the Subversion code (which I presume it is) it'll still be there when you're using git-svn. – JesperE Aug 21 '09 at 12:42
  • 1
    @vava: are the workspaces getting *corrupted*, or are people just making changes which are confusing to other users (moving, renaming, etc.)? In the latter case you have a user training issue, and not a Subversion bug at all. – JesperE Aug 21 '09 at 12:45
  • @JesperE, no, working copy gets corrupted. I'm not sure git-svn will help but I can try, can't I? – vava Aug 21 '09 at 12:50
  • Do you use file:/// to connect to your shared repository? – Bert Huijben Aug 21 '09 at 12:52
  • @Bert, no, https://... Repository is not in my local network, in fact there's a good chance it is in another country :) – vava Aug 21 '09 at 12:54
  • @vava: go ahead and try. If you get another working copy corruption, at least you have another data point. – JesperE Aug 21 '09 at 18:39

8 Answers8

4

Pros:

  • Everything that Git is good for:
    • Network-free access to all old commits
    • Commit and rebase in Git (again, network-free) and then git svn dcommit to push all the changes to SVN for a nice clean commit
    • Cheap local branching (not sure why you say this doesn't work so well)
  • Don't have to deal with SVN so much :)

Cons:

  • Much better workflow if you already know both Git and SVN (i.e., not so good for new source control users)
  • Will confuse anyone else if they look at what you're doing
  • Some features of SVN (such as svn:keywords) not available/convenient
Will Robertson
  • 62,540
  • 32
  • 99
  • 117
  • I'm forced to use SVN at university and still prefer to use Git with the SVN bridge. That said, you cannot fully take advantage of Git until SVN is out of the equation. – Tate Johnson Aug 21 '09 at 10:18
3

These are the spesific pro and con using git-svn. So it's not really about the git itself.

Pro:

The tendency of people using svn is to commit big changes all at once, because you need to commit over the wire. This approach can be bad because sometimes the changes might not related with each other. e.g: You can have changes with bugfixes and changes for new feature committed on one changeset. With git I can commit as often to my local git repository (especially when I'm not connected to a network) and have a changeset as small as possible. I then commit to svn (using 'git svn dcommit') when the whole big changes is ready.

Con:

The con of having svn as the remote repository is merging, especially when there are conflicts. It can be painful sometimes. I use IntelliJ as my IDE and to resolve conflicts, I have to go to command line to fix it. Knowing that I encounter this problem often, I have documented it and now it doesn't become a big deal anymore for me.

Joshua Partogi
  • 16,167
  • 14
  • 53
  • 75
3

I migrated to git using git-svn. Our svn repository is still in tact and we still get all of the "git awesomeness". Essentially after the git-svn clone you branch that again as your 'trunk'. Everyone using git will branch from here. When you need to get updates from svn you simply do git-svn rebase and then do git merge --squash from the svn branch to the new 'trunk'. And visa versa. This will mean your history on the svn repo will not match whats in git. When you do more then one merge, at some point your going to have to start grafting commits because the history doesnt match. However if you graft the HEAD of your git trunk to the last commit id that was a squashed merge you will get the same effect.

Ok so let me break this down the best I can with an example.

svn repo: svn://xyz.com/myproject

git svn clone svn://xyz.com/myproject

This should leave you with a normal git-svn setup with a master branch which has the same history as the svn repository.

git checkout -b git_trunk

git_trunk becomes the "trunk" for the git users.

This branch can be used freely like any other git repository.

Now you need to synchronize these two branches via git merge --squash

For instance.. merging from the master svn branch to git_trunk

git checkout git_trunk
git merge --squash master
git commit -a

You would do the same thing in order to merge from git_trunk to the master svn except you would execute

git svn dcommit

This will push it back to svn.

So the complicated part here is that since we are using --squash the merge history is lost and the only common ancestor git will ever know about is the branch point. This will mean merge conflicts. The way i solved it was by doing something like this

Merging from git_trunk to master. First I take the commit id of the last squash on git_trunk. Lets call it ABCDEFG. Then i get the commit-d of git_trunk. Lets say its HIJKLMNO

echo "HIJKLMNO ABCDEFG" > .git/info/grafts

This will tell git when merging that the most common ancestor is the most recent squashed commit.

Its not perfect but it works great for me. Especially now since almost everyone is on git.

  • So, you made a public git repository that everyone who likes the git is using and once in a while you just commit all of those people changes into main subversion one. Poor people who left on svn can't use blame anymore :) – vava Aug 23 '09 at 02:24
2

My experience with git-svn is that it is primarily useful to (experienced) git-users who want to have a git-like interface to a subversion repo. Assimilating both the git set of concepts and the limitations of git-svn was too much at least for me.

If you can, I'd recommend that you switch to git entirely.

I've seen many people complaining about Subversion, but as far as I know it is fairly stable. Are you sure you aren't having hardware trouble?

JesperE
  • 63,317
  • 21
  • 138
  • 197
  • Yes, I'm sure :) It just sometimes breaks when file names are too long or if connection goes south in the middle of commit. Dealing with 2GB repository is just not easy for poor subversion. Too bad I can't switch to git entirely. – vava Aug 21 '09 at 08:02
  • Have you asked for help in the SVN mailing list(s)? I bet they'd be very interested in such issues. – sbi Aug 21 '09 at 09:07
  • 2
    I think they'd be interested in any case. A corrupt repo is a bug the Subversion developers take *VERY* seriously, IMO. And BTW, 2GB repo should not be any problems whatsoever. We've got a server 50+ repos with a total size of ~50GB. (And using git-svn won't help you if Subversion is corrupting the repo.) – JesperE Aug 21 '09 at 12:39
  • I can tell you that size is not a matter of subversion. I handle a lot of repositories which have sizes between 10-20 gByte. And long filenames is only a problem in deep nested workingcopys. However all filesystems have this limitations (a path can only be 255 chars ) – Peter Parker Aug 21 '09 at 12:45
  • Yes, I know about path size limitation. I just hate when subversion can download file without any issues but can't create it's own metadata because path for it is slightly longer and then refuses to update and commit any other files because of that. This is really annoying. – vava Aug 21 '09 at 13:14
  • @Peter: 255 is not a universal path size limit. On windows, MAX_PATH is actually 260 characters, and ext2/ext3 has a much larger path limit than that. – JesperE Aug 21 '09 at 18:26
1

If the usage is:

  • "We keep SVN but have Git for quick internal branching", no need to use git-svn: you can 'git init' directly within a branch of your subversion workspace and git hack directly within that portion of your code.

But if this is:

  • "We maintain both a central SVN repo and a Git repo", then things are bit more complicated, because:
    • a simple git-svn will reproduce the "SVN branches" (actually simple directory with copies in it), so I would recommend using svn2git and git2svn
    • trying to import everything in one Git repository is not always a good idea (see "What are the git limits?"): if your system is composed of different modules which can be developed independently one from another, they can live within one single SVN central repository, but they should have their own respective Git repo (in order to be able to pull only the modules you need)
Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
1

I think the change to git will not solve your problems. If you have "non-programmers" inside your working force and they will break others people working copy (I assume by renaming/removing directories or files).

If you will use git-svn or git or whatever other VCS and people still rename/remove their directories, how should this get any better?

I think you should try to train some of the people to understand the basic concepts of VCS.

If the people do not understand SVN workflows, I doubt they will master git-svn, or git.

Peter Parker
  • 29,093
  • 5
  • 52
  • 80
  • That's why I want to hide behind git-svn :) I don't know this for sure but I'd like to think that git just more advanced and will not break that easily. – vava Aug 21 '09 at 12:34
  • git-svn will introduce more complexity and will break down as easily as svn, if you delete and rename files wildly and tries to merge. You really should search for the source of your problems. – Peter Parker Aug 21 '09 at 12:43
0

I can see no trouble to migrate all svn repository to git, keeping history and all other in it, and than to switch to git entirely.

2Gb is to much for a single repository. May be it worth to split it into some parts?

Vestel
  • 1,005
  • 1
  • 11
  • 25
  • Unfortunately, I'm not the only employee :) And those non-programmers people could understand Tortoise SVN for some extent, git would be too harsh on them. So migrating to git is not an option sadly. – vava Aug 21 '09 at 08:18
0

Tom Preston-Werner, Chris Wanstrath and Scott Chacon —Git, GitHub and Social Coding: http://developer.yahoo.com/yui/theater/video.php?v=prestonwerner-github