3 ms·

In my experience, using a system that tries to bridge between two technologies like Git and SVN will result in having to deal with a lot more weirdnesses than e

by cool-RR 15y ago

In my experience, using a system that tries to bridge between two technologies like Git and SVN will result in having to deal with a lot more weirdnesses than each technology individually. In general, the amount of bullshit you'll have to deal with from a piece of software is inversely proportional to the number of users of that software. And the number of users of git-svn is much lower than both SVN's and Git's.

JustAGeek 15y ago
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." ( http://svnbook.red-bean.com/en/1.5/svn.branchmerge.using.html 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
darklajid 15y ago
Hmm.. But you didn't try, now, did you? You state you used SVN twice only and the first time was very brief. So.. - The claim is useless (your experience in general might not be relevant here) - The 'inversely proportional' line is a gut feeling, not helping - and the whole comment here was a copy/paste from your blog comment. Several people point out that there might've been a good solution and you cross-post 'Yeah.. I don't believe that. And let me hide my personal belief behind some math related statements' and even refer to that answer of yours when _even more people_ tell you that you should've tried git-svn (again on the blog, replying with 'see what I replied to X')? I'm confused. Why are you so confident that you didn't miss out an easy solution?
- cool-RR 15y ago
  Does git-gui work with git-svn?
  - JustAGeek 15y ago
    Yes, it does, why shouldn't it? 1. Edit some files 2. start git gui and commit 3. repeat 1+2 as many times as you want 4. git svn dcommit 5. all local commits will now be committed to the SVN repo
mansr 15y ago
One thing I've tripped over with git-svn was SVN's inability to replace a directory with a file in a single commit. Git allowed this (as it should), but pushing the commit to the SVN repo failed with some strange error message. On the whole, I find git-svn much nicer to work with than raw SVN. I can have local branches for work in progress, merge/rebase and with/onto trunk with ease, queue up multiple commits before pushing, work offline, etc. Using plain SVN, by comparison, feels like driving blindfolded in reverse with the handbrake on. CVS is like additionally having your head in a bucket of water.
gte910h 15y ago
You'd think that, but git-svn is far far easier than working in just svn.

by cool-RR 15y ago

JustAGeek 15y ago

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." ( http://svnbook.red-bean.com/en/1.5/svn.branchmerge.using.html 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

darklajid 15y ago

Hmm.. But you didn't try, now, did you? You state you used SVN twice only and the first time was very brief. So.. - The claim is useless (your experience in general might not be relevant here) - The 'inversely proportional' line is a gut feeling, not helping - and the whole comment here was a copy/paste from your blog comment. Several people point out that there might've been a good solution and you cross-post 'Yeah.. I don't believe that. And let me hide my personal belief behind some math related statements' and even refer to that answer of yours when _even more people_ tell you that you should've tried git-svn (again on the blog, replying with 'see what I replied to X')? I'm confused. Why are you so confident that you didn't miss out an easy solution?

cool-RR 15y ago
Does git-gui work with git-svn?
- JustAGeek 15y ago
  Yes, it does, why shouldn't it? 1. Edit some files 2. start git gui and commit 3. repeat 1+2 as many times as you want 4. git svn dcommit 5. all local commits will now be committed to the SVN repo

mansr 15y ago

One thing I've tripped over with git-svn was SVN's inability to replace a directory with a file in a single commit. Git allowed this (as it should), but pushing the commit to the SVN repo failed with some strange error message. On the whole, I find git-svn much nicer to work with than raw SVN. I can have local branches for work in progress, merge/rebase and with/onto trunk with ease, queue up multiple commits before pushing, work offline, etc. Using plain SVN, by comparison, feels like driving blindfolded in reverse with the handbrake on. CVS is like additionally having your head in a bucket of water.

gte910h 15y ago

You'd think that, but git-svn is far far easier than working in just svn.