Comments on: Don’t migrate your VCS http://www.taylor.se/blog/2009/04/30/dont-migrate-your-vcs/ Smart consulting Tue, 08 Jun 2010 05:02:39 +0000 hourly 1 http://wordpress.org/?v=3.0 By: wow gold http://www.taylor.se/blog/2009/04/30/dont-migrate-your-vcs/comment-page-1/#comment-20277 wow gold Tue, 09 Mar 2010 10:44:38 +0000 http://www.taylor.se/blog/?p=260#comment-20277 wow gold wow gold wow gold
wow gold

]]> By: YV29Chloe http://www.taylor.se/blog/2009/04/30/dont-migrate-your-vcs/comment-page-1/#comment-19924 YV29Chloe Sun, 24 Jan 2010 17:47:47 +0000 http://www.taylor.se/blog/?p=260#comment-19924 The <a href="http://www.master-dissertations.com" rel="nofollow">dissertation writing service</a> will offer people with the phd thesis but the professional idea just about this good post scholars would notice only on this page. The dissertation writing service will offer people with the phd thesis but the professional idea just about this good post scholars would notice only on this page.

]]> By: Andres http://www.taylor.se/blog/2009/04/30/dont-migrate-your-vcs/comment-page-1/#comment-18248 Andres Sat, 02 May 2009 17:07:48 +0000 http://www.taylor.se/blog/?p=260#comment-18248 I am glad to hear different opinions. Kerry: Didn't know that. If it works well, you should probably use it. RJ: I haven't had the experience you describe. And, truth be told, I was aiming at the corporate user, as that is almost exclusively where I am. Maybe there's a difference there? MF: I know that I haven't missed it at all, any of the times I've done exactly what I describe here. Jeremy: I'm claiming that even though you might in the future want to see the history, the cost of migrating is much bigger than the gain of doing it. L.M. Again, I don't share your experience. I rarely use blame. I think the last commenter might be right on target - in an agile environment, stuff move around quite a lot, and so blame-history is pretty unreliable. Thanks for sharing your opinions! I am glad to hear different opinions.
Kerry: Didn’t know that. If it works well, you should probably use it.
RJ: I haven’t had the experience you describe. And, truth be told, I was aiming at the corporate user, as that is almost exclusively where I am. Maybe there’s a difference there?
MF: I know that I haven’t missed it at all, any of the times I’ve done exactly what I describe here.
Jeremy: I’m claiming that even though you might in the future want to see the history, the cost of migrating is much bigger than the gain of doing it.
L.M. Again, I don’t share your experience. I rarely use blame. I think the last commenter might be right on target – in an agile environment, stuff move around quite a lot, and so blame-history is pretty unreliable.

Thanks for sharing your opinions!

]]> By: Anonymous http://www.taylor.se/blog/2009/04/30/dont-migrate-your-vcs/comment-page-1/#comment-18237 Anonymous Thu, 30 Apr 2009 20:42:02 +0000 http://www.taylor.se/blog/?p=260#comment-18237 i can see this working fine on an agile project with a fairly active codebase with plenty of refactoring (where the history is less important), but on a more traditional project where most code tends to stay the way it was written (bugs and all) for most of it's life the history is really, really useful. i can see this working fine on an agile project with a fairly active codebase with plenty of refactoring (where the history is less important), but on a more traditional project where most code tends to stay the way it was written (bugs and all) for most of it’s life the history is really, really useful.

]]> By: l.m.orchard http://www.taylor.se/blog/2009/04/30/dont-migrate-your-vcs/comment-page-1/#comment-18236 l.m.orchard Thu, 30 Apr 2009 20:21:16 +0000 http://www.taylor.se/blog/?p=260#comment-18236 The first time you try to run `git blame` or some such on your new repository is when you will curse and start wasting the next hour or so digging through the old repo. The first time you try to run `git blame` or some such on your new repository is when you will curse and start wasting the next hour or so digging through the old repo.

]]> By: Jeremy http://www.taylor.se/blog/2009/04/30/dont-migrate-your-vcs/comment-page-1/#comment-18235 Jeremy Thu, 30 Apr 2009 20:16:46 +0000 http://www.taylor.se/blog/?p=260#comment-18235 I have had to revive servers that hadn't been plugged-in for three years to recover history that wasn't migrated. Reattaching that box to the network and finding a client that worked on XP and still talked to the version of the server software was hard. Migrate history if possible. Relegate it to its own read-only project if you must. But IS and the poor engineer tasked with recovering it in the future will be much happier with you if you can migrate and officially decommission the old server instance. I have had to revive servers that hadn’t been plugged-in for three years to recover history that wasn’t migrated. Reattaching that box to the network and finding a client that worked on XP and still talked to the version of the server software was hard.

Migrate history if possible. Relegate it to its own read-only project if you must. But IS and the poor engineer tasked with recovering it in the future will be much happier with you if you can migrate and officially decommission the old server instance.

]]> By: MF http://www.taylor.se/blog/2009/04/30/dont-migrate-your-vcs/comment-page-1/#comment-18234 MF Thu, 30 Apr 2009 17:40:06 +0000 http://www.taylor.se/blog/?p=260#comment-18234 This is always easy to say until you find that the old cruft is one more thing to maintain (and no one wants to babysit the red headed step child). Or that you need to browse the old history and don't remember the commands and really wish that the old vcs has some source tracking features some of the new version control systems have. I've personally converted a monstrous history and it's come in handy more frequently than I had originally anticipated. Besides, it was not that difficult and it's only a one time cost. More mindspace to work on more pressing matters down the line, I personally think, is worth the effort. This is always easy to say until you find that the old cruft is one more thing to maintain (and no one wants to babysit the red headed step child). Or that you need to browse the old history and don’t remember the commands and really wish that the old vcs has some source tracking features some of the new version control systems have.

I’ve personally converted a monstrous history and it’s come in handy more frequently than I had originally anticipated. Besides, it was not that difficult and it’s only a one time cost. More mindspace to work on more pressing matters down the line, I personally think, is worth the effort.

]]> By: RJ Ryan http://www.taylor.se/blog/2009/04/30/dont-migrate-your-vcs/comment-page-1/#comment-18233 RJ Ryan Thu, 30 Apr 2009 17:03:04 +0000 http://www.taylor.se/blog/?p=260#comment-18233 NO! You are wrong. Don't commit your trunk as the first commit! Use a tool to migrate your history. Holy crap. It is dead easy. There is a migration tool for every VCS. The future maintainers of your open source project will thank you. Having to dig in some old crufty VCS for history is very annoying, and if your project is of any decent size, you will be inconveniencing many people. NO! You are wrong. Don’t commit your trunk as the first commit! Use a tool to migrate your history. Holy crap. It is dead easy. There is a migration tool for every VCS. The future maintainers of your open source project will thank you. Having to dig in some old crufty VCS for history is very annoying, and if your project is of any decent size, you will be inconveniencing many people.

]]> By: Kerry Buckley http://www.taylor.se/blog/2009/04/30/dont-migrate-your-vcs/comment-page-1/#comment-18232 Kerry Buckley Thu, 30 Apr 2009 10:56:09 +0000 http://www.taylor.se/blog/?p=260#comment-18232 The exception being when the new VCS comes with a tool for doing the migration. For instance a simple "git svn clone " is just as easy as creating a new git repo from your old svn head. The exception being when the new VCS comes with a tool for doing the migration. For instance a simple “git svn clone ” is just as easy as creating a new git repo from your old svn head.

]]>