Wich is the best way to prepare a team for migration from svn to mercurial?
Wich problems may appear in the migration?
How to solve them?
views:
570answers:
2
+7
A:
Your biggest hassle will be comprehension of concepts.
The multiple-named-branches/multiple-heads sharing the same logical space thing appears to be the biggest stumbling block, along with the all-branches turn up in all clones deal.
Your only way to solve this is mandate they read the documentation, in full, and test them on their understanding of the documentation, and don't migrate until you do.
This may sound rash, but having had personal experience with this in the realm of unintentional merging of branches that were unintended to be merged, by multiple people on multiple occasions, I have to basically say you need to know they can handle it, or your job will become a living nightmare. #265944 Backing out a backwards merge
Further more, read the documentation on hooks yourself, and learn how to write hooks on your most critical shared repository so that recognized bad problems are not permitted to turn up.
Kent Fredric
2008-11-24 15:56:51
I was in the mercurial channel when you first came in with the question to which you liked. I do think you could've avoided a lot of the hassles by eschewing named branches, but it did sound like you had a hard workgroup with which to work.
Ry4an
2008-11-25 07:44:57
A:
We made the transition easier by limiting the number of ways people could screw things ups -- both by banning certain features and by picking a conceptually easier workflow.
We said "no named branches" and went instead with the clones-as-branches mechanism that Mercurial makes easy and efficient.
We said "no mercurial queues" because they modify existing repos in unexpected ways.
We also picked a workflow that had just a few people pushing into a "central" respository. For every bug/feature a developer is going to work on he or she makes a clone of the central repository on the central server. They then clone that bugfig-clone onto their local machine. They can push a series of changes into their on-server clone and when done the release owner pulls from their bugfix clone into the central repo.
Lastly, I'd suggest you make sure all your people know what "hg parents" does and what "hg revert" doesn't do (it only modifies your working directory never nor repository).
Ry4an
2008-11-25 07:43:11