Weblog entry #191 for Steve
See all weblog entries made by Steve.
My migration over to mercurial (away from CVS) is going well.
So far I've moved the code which generates our planet - the next job is to move the code behind the main site.
I'm getting the hang of the migrations now, having moved several projects.
All being well my CVS server will be empty within the week.
Comments on this Entry
[ Parent | Reply to this comment ]
[ Send Message | View Steve's Scratchpad | View Weblogs ]
I'm using a tool called Tailor, via this howto.
All history is preserved and it is mostly painless. Just a little slow.
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
[ Send Message | View Steve's Scratchpad | View Weblogs ]
My later reply to ajt probably sums it up pretty well...
[ Parent | Reply to this comment ]
I'm just curious, as I plan to migrate off CVS when I eventually deploy a new server at home and was planning on a svn/svk solution. Work is currently in the process of moving from CVS to SVN, which is partly why I was thinking of doing the same.
--
"It's Not Magic, It's Work"
Adam
[ Parent | Reply to this comment ]
[ Send Message | View Steve's Scratchpad | View Weblogs ]
I don't consider subversion as anything other than than a slight improvement over CVS. In my opinion subversion was designed to look, feel, and behave much like CVS but with a few minor changes such as atomic commit, and rename-tracking.
It seems to me that if you're going to migrate away from CVS that you should pick something significantly better than it, not just something witha few of the issues fixed.
For me that means distributed.
That immediately limitted my choice to three systems:
- darcs
- git
- mercurial
(There are more distributed systems, I ignored them.)
Darcs is adequate, but I use it at work and we've had problems with memory usage when merging changesets, also permissions issues are a recurring problem. (Probaby this is more our fault than darcs's)
Git in theory I like, but in practise the need to "repack" the repository to stop it from consuming disk space is a big issue. So is the sheer number of commands and the possability of cnfusion.
So mercurial pretty much win by default! Having said that mercurial does have a lot of nice things to recommend it, and I'm enjoying it a lot. The only minor problem is that the version in etch doesn't support symlinks; but a backport of the version which does is available on backports.org.
[ Parent | Reply to this comment ]
At work it's more a case of which has the least possible risk? what is the herd doing? - we'll do that. I'm not saying it's a better or worse approach but as a general rule we're fairly conservative in how we change things - if we get it wrong people could die.
--
"It's Not Magic, It's Work"
Adam
[ Parent | Reply to this comment ]