How to rewind ("back up") a git-svn repo

My company uses Subversion for most of its version control needs. But, I find I like the flexibility git affords me better. So, I've been using git, via git-svn, for some time now, with generally only a few problems.

However, not long ago I transfered a repository to another computer, and messed up my git settings (I set AutoCrLf to true... oops).

Anyway, this messed up my repo pretty good, to the point that I couldn't even do a git svn rebase without it failing with the error "Incomplete data: Delta source ended unexpectedly"

Turns out, in order to fix this, you have to re-get the entire repository, or at least without re-getting the commits that were checked out with AutoCrLf (remember, I had the git repo from another computer, so most of the history was good).

So, how do you rewind git-svn to a particular revision?

Thanks to the handy git-svn documentation:

git svn reset -r [svn revision number] -p

And then, just git svn rebase as normal.

Difference in POV between Centralized VCS and Distributed VCS

'However, the total cost of branching is paid by reduced code velocity to main, merge conflicts and additional testing can be expensive. Throughout this guidance we ask the user to confirm that a branch is really needed and always ask the question "how does this branch support my development project?"'
-- from the TFS branching guide.

I came across this interesting passage yesterday, and I was struck by the profound difference in point of view between centralized version control and distributed version control.

In distributed version control systems (dvcs), branching is fundamental (in most scenarios): every "checkout" is really a branch of the repository, with full history. Therefore the focus in developing dvcs has been on making branching and merging as simple, quick and painless as possible.

Now, arguably, branching is also fundamental to all version control; after all, when you check out a copy of the code and modify it, you make a kind of lightweight, local branch for your changes that is quickly merged back into the trunk. But, with centralized version control, the focus is on control of the codebase, which is concentrated in the trunk. So, not only is branching not optimized (because of the lack of focus), but it is indirectly made more costly by the controls put on the trunk. And, because local checkouts aren't recognized as 'branches', you lack most of the usual tools for managing them separately from the trunk/server, like full history and an easy way to exchange patches with another developer.

Now, this isn't to say that the above advice isn't germane (PSP: take a shot!). If you are using a centralized version control tool, then you should absolutely consider the costs associated with branching, because it is quite expensive. And, arguably, you could go crazy with dvcs as well, but it takes a lot more work, I think. But the elaborate systems that the aforementioned branching guide mentions for scenarios just seem baroque and unnecessary when considered from the context of a dvcs.

Better diff/merge

Wouldn't it be nice if your VCS/SCM understood the code that was checked in, so that it could show diffs that were correctly contained?

For example, I modify a method and delete the method right after it. It shouldn't show that as a single change, but as two (one change for the modify, one for the delete). Or if I move a method in the source file but leave it otherwise unchanged (or even change it!): it shows as a 'move' (and potentially, then, a change as well!).

Some of this could be done without understanding the code much, eg, looking for identical blocks of text between the new and old files, which constitute 'moves'.

And it wouldn't have to happen when sending changes to the server, just when comparing the two versions for human consumption.