5 ms·

You guys laugh but migrating version control systems can be one of the most nightmarish projects an organization chooses to undertake. It's right alongside rewr

by jtchang 15y ago

You guys laugh but migrating version control systems can be one of the most nightmarish projects an organization chooses to undertake. It's right alongside rewriting mainframe software (that probably has been working for 20 years) and an overhaul of the employee HR systems. It's scary. It's fraught with pitfalls. But in the end everyone hopes the result is a better tool. We need more of these writeups. I personally love git. I just think the learning curve is steep. Think you know git? Next day someone teaches you some fancy new command you didn't even know existed. I think git is really taught wrong in a lot of tutorials. They never focus on workflow and determining what works for you and your team (if you have one). Once you decide on the workflow all the git commands you need become apparent.

cynicalkane 15y ago
It's best to think of Git not as a version control framework but as a library of functions on a directory-tree data structure (edit: with a history). With this mental model, you realize that 1) there's all kinds of crazy things you can do 2) for a given crazy thing someone's probably already done it, and if it's not too far-out there's probably a command for it. The reflog makes uncollected garbage available to the user, meaning that if you screw up you can just roll back to an old commit, carrying with it an entire history, even if that commit is no longer referenced by the repo.
- jcheng 15y ago
  > on a directory-tree data structure Or on a directed acyclic graph of refs; that's the definition that made everything click for me.
  - xpaulbettsx 15y ago
    The key that makes things click for me is, the Commit is the most important 'unit' of Git. Tags, branches, pseudo-refs like HEAD are all just mutable or immutable (like tags) pointers to commits. http://tom.preston-werner.com/2009/05/19/the-git-parable.html http://tom.preston-werner.com/2009/05/19/the-git-parable.htm... is absolutely worth your time if the above statement didn't trigger a lightbulb in your head
    - gwern 15y ago
      What is this, a discussion of Haskell monad tutorials? :)
- mattmanser 15y ago
  Seriously? It's a VCS and that's all it is. Your comment doesn't address the parent's comment at all. Moving VCS is hard in any team with more than a few members, especially when the change is coming from a few and not everyone. I remember my old company moving from MS VSS to svn, all we hear was 'why, VSS works!', even though it was a nightmare compared to svn. Of course the change had a bunch of teething problems and the conservatives pointed and moaned more. But who in their right mind would say VSS is better than SVN? Any organisational change is hard, no matter how 'obviously' better it is.
finnw 15y ago
A company I used to work for attempted to migrate once and nearly gave up, but then realised it was feasible (and not very expensive) if we did not insist on preserving the history. So the new revisions were kept in Mercurial and the old ones in CVS. A slight inconvenience for the first year, but after that nearly all of the interesting revisions were in the new system. As for the legacy systems, they already required us to maintain Windows NT4 boxes and a no-longer-supported C compiler, so the additional overhead of a second VCS was tiny by comparison.
pnathan 15y ago
Migrating source code systems is intense. It's very much a superlinear scaling question - the more people involved, the more training, the more chance for errors, the more miscommunications, the more tooling needed. Where I work, we've been doing some migrating from ClearCase to Mercurial. Pretty intense work.
ConstantineXVI 15y ago
We (10-person startup) actually migrated from TFS to Git a few months ago. The technical migration was mostly smooth (found a TFS->Git export tool); like many other people, the main issue's been the DVCS culture shock. I was "lucky" to come on right as we were beginning the migration (which I ended up leading by default), so I haven't had all of the TFSisms to work out of my system that everyone else did.

by jtchang 15y ago

cynicalkane 15y ago

It's best to think of Git not as a version control framework but as a library of functions on a directory-tree data structure (edit: with a history). With this mental model, you realize that 1) there's all kinds of crazy things you can do 2) for a given crazy thing someone's probably already done it, and if it's not too far-out there's probably a command for it. The reflog makes uncollected garbage available to the user, meaning that if you screw up you can just roll back to an old commit, carrying with it an entire history, even if that commit is no longer referenced by the repo.

jcheng 15y ago
> on a directory-tree data structure Or on a directed acyclic graph of refs; that's the definition that made everything click for me.
- xpaulbettsx 15y ago
  The key that makes things click for me is, the Commit is the most important 'unit' of Git. Tags, branches, pseudo-refs like HEAD are all just mutable or immutable (like tags) pointers to commits. http://tom.preston-werner.com/2009/05/19/the-git-parable.html http://tom.preston-werner.com/2009/05/19/the-git-parable.htm... is absolutely worth your time if the above statement didn't trigger a lightbulb in your head
  - gwern 15y ago
    What is this, a discussion of Haskell monad tutorials? :)
mattmanser 15y ago
Seriously? It's a VCS and that's all it is. Your comment doesn't address the parent's comment at all. Moving VCS is hard in any team with more than a few members, especially when the change is coming from a few and not everyone. I remember my old company moving from MS VSS to svn, all we hear was 'why, VSS works!', even though it was a nightmare compared to svn. Of course the change had a bunch of teething problems and the conservatives pointed and moaned more. But who in their right mind would say VSS is better than SVN? Any organisational change is hard, no matter how 'obviously' better it is.

finnw 15y ago

A company I used to work for attempted to migrate once and nearly gave up, but then realised it was feasible (and not very expensive) if we did not insist on preserving the history. So the new revisions were kept in Mercurial and the old ones in CVS. A slight inconvenience for the first year, but after that nearly all of the interesting revisions were in the new system. As for the legacy systems, they already required us to maintain Windows NT4 boxes and a no-longer-supported C compiler, so the additional overhead of a second VCS was tiny by comparison.

pnathan 15y ago

Migrating source code systems is intense. It's very much a superlinear scaling question - the more people involved, the more training, the more chance for errors, the more miscommunications, the more tooling needed. Where I work, we've been doing some migrating from ClearCase to Mercurial. Pretty intense work.

ConstantineXVI 15y ago

We (10-person startup) actually migrated from TFS to Git a few months ago. The technical migration was mostly smooth (found a TFS->Git export tool); like many other people, the main issue's been the DVCS culture shock. I was "lucky" to come on right as we were beginning the migration (which I ended up leading by default), so I haven't had all of the TFSisms to work out of my system that everyone else did.