4 ms·

It seems to me that a lot of the evangelists of one source control tool over another fail to realize that for companies that -aren't- startups, migrating betwee

It seems to me that a lot of the evangelists of one source control tool over another fail to realize that for companies that -aren't- startups, migrating between tools is a lot of work. Reconfiguring build servers, rewriting documentation/wiki pages which have SVN Uris (or anything at all regarding existing source control) in them for projects that have existed 5-10 years as well as having an entire team learn a new source control tool is no task to be taken lightly.

selectnull 16y ago
Exactly! I have 15 GB of svn repositories. I don't plan to migrate them. I use mercurial for new projects and I'm fine with old stuff to live in svn. Just like I use more than one programming language, I use more than one OS, I use more than one database backend...
- pilif 16y ago
  Whenever I'm touching one of my old projects (some even in CVS), I'm migrating them to the system I'm using at the time. Currently that's git. So now I'm looking back on 52 repositories. 16 in CVS, 14 in subversion and 22 in git (all of them counted only once) created over the last 10 years.
  - selectnull 16y ago
    That's certainly one good way to go. The other is to leave them where they are. Whatever works is the good way.
jarin 16y ago
In my experience, going from SVN to Git has been as simple as doing git-svn clone and then pushing up to Github (or Assembla). Then again, I agree that there's a lot for the users to learn, so it's probably best done during a refactoring phase and you need at least one Git master to be available to answer any questions.
- pilif 16y ago
  The migration on a technical level is easy. I did spend multiple hours though fixing non-fast-forwarded merges, accidentally created merges after pulling, incorrect author names and one accidental force-push. All of these I could have prevented using policy on the server, but I would still have had to help explaining the underlying issues in order to a) get the broken commit in and b) make sure it doesn't happen again. Explaining takes much longer than just fixing. The problem isn't technical. It's human. The more employees/team members you have, the more complicated it will become to put all on the same boat. My experience above comes from a team with 4 people of which two were already git users (one of them was me). I don't want to think what this migration would have meant if we were 10 or even 100 people.

selectnull 16y ago

Exactly! I have 15 GB of svn repositories. I don't plan to migrate them. I use mercurial for new projects and I'm fine with old stuff to live in svn. Just like I use more than one programming language, I use more than one OS, I use more than one database backend...

pilif 16y ago
Whenever I'm touching one of my old projects (some even in CVS), I'm migrating them to the system I'm using at the time. Currently that's git. So now I'm looking back on 52 repositories. 16 in CVS, 14 in subversion and 22 in git (all of them counted only once) created over the last 10 years.
- selectnull 16y ago
  That's certainly one good way to go. The other is to leave them where they are. Whatever works is the good way.

jarin 16y ago

In my experience, going from SVN to Git has been as simple as doing git-svn clone and then pushing up to Github (or Assembla). Then again, I agree that there's a lot for the users to learn, so it's probably best done during a refactoring phase and you need at least one Git master to be available to answer any questions.

pilif 16y ago
The migration on a technical level is easy. I did spend multiple hours though fixing non-fast-forwarded merges, accidentally created merges after pulling, incorrect author names and one accidental force-push. All of these I could have prevented using policy on the server, but I would still have had to help explaining the underlying issues in order to a) get the broken commit in and b) make sure it doesn't happen again. Explaining takes much longer than just fixing. The problem isn't technical. It's human. The more employees/team members you have, the more complicated it will become to put all on the same boat. My experience above comes from a team with 4 people of which two were already git users (one of them was me). I don't want to think what this migration would have meant if we were 10 or even 100 people.