4 ms·

Well, this begs the question, why not just let git do all that diff-packing and 99% of the conflict resolution crap for you? As long as you don't mind spending

Well, this begs the question, why not just let git do all that diff-packing and 99% of the conflict resolution crap for you? As long as you don't mind spending a weekend or a few evenings reading about the new tool and how it works (like any new addition to your skillset), that is.

barrkel 16y ago
I'm afraid the git clone behaviour is unusable for the svn repository I work from. A clean pulled tree is over 1GB at the moment I believe, and contains many binary files (static libraries etc.) that aren't rebuilt that often, but often enough to make the repository as a whole very large. I don't know exactly how large it is, but it's large enough that it would take many weeks to download over VPN. Just getting a fresh tree takes over 24 hours as it is. As for diff packing, it's as simple as this on the bash command line: collect-patch $(now)-hint.patch foo/{bar,baz} The collect-patch script will do an svn diff over foo/bar and foo/baz from the root of my working directory, and deposit the results in a file in my current directory (e.g. 2010-05-13_15-50-whatever.patch). Then, I can revert local changes: revert 2010-05-13_15-50-whatever.patch (This reverts changes to the files listed as modified in the patch.) Because it's a file, I get completion on that. And to apply (e.g. after an svn update): apply 2010-05-13_15-50-whatever.patch If things get more complicated, and there are conflicts in the lines modified by my patch and the updated source (which is less than 1% of the time), then I do: manual-merge 2010-05-13_15-50-whatever.patch That uses a tool (BeyondCompare 3) to do three-way merging between the original revision of my patch, my local edit to the original revision, and the new revision that's been gotten locally. BC3 can auto-merge for all non-conflicting edit sections, but be interactive with a nice diff display and editing if there's a conflict (/automerge and /reviewconflicts arguments to bcomp). I'm sure I could migrate this scheme onto an analogous git scheme that could keep track of the merges better, but in practice this scheme is enough - and because I wrote it, I'm intimately familiar with its mechanics, so I can extend it, and I'm not at risk of file loss, etc.

barrkel 16y ago

I'm afraid the git clone behaviour is unusable for the svn repository I work from. A clean pulled tree is over 1GB at the moment I believe, and contains many binary files (static libraries etc.) that aren't rebuilt that often, but often enough to make the repository as a whole very large. I don't know exactly how large it is, but it's large enough that it would take many weeks to download over VPN. Just getting a fresh tree takes over 24 hours as it is. As for diff packing, it's as simple as this on the bash command line: collect-patch $(now)-hint.patch foo/{bar,baz} The collect-patch script will do an svn diff over foo/bar and foo/baz from the root of my working directory, and deposit the results in a file in my current directory (e.g. 2010-05-13_15-50-whatever.patch). Then, I can revert local changes: revert 2010-05-13_15-50-whatever.patch (This reverts changes to the files listed as modified in the patch.) Because it's a file, I get completion on that. And to apply (e.g. after an svn update): apply 2010-05-13_15-50-whatever.patch If things get more complicated, and there are conflicts in the lines modified by my patch and the updated source (which is less than 1% of the time), then I do: manual-merge 2010-05-13_15-50-whatever.patch That uses a tool (BeyondCompare 3) to do three-way merging between the original revision of my patch, my local edit to the original revision, and the new revision that's been gotten locally. BC3 can auto-merge for all non-conflicting edit sections, but be interactive with a nice diff display and editing if there's a conflict (/automerge and /reviewconflicts arguments to bcomp). I'm sure I could migrate this scheme onto an analogous git scheme that could keep track of the merges better, but in practice this scheme is enough - and because I wrote it, I'm intimately familiar with its mechanics, so I can extend it, and I'm not at risk of file loss, etc.