> In other words, two more steps, and simple ones at that. It doesn't > seem so bad to me, and it certainly hasn't proven unworkable in my own > practice gatekeeping in RBridges and Picea, and being a gateling of > SCM Migration.
It's not unworkable, I just find it a poor fit for what I need. Obviously, there are a spectrum of different ways to do development based on preferences and needs. I'm sure I'm not the only one who merges directly inside a repo rather than creating a merge repo. Further, regardless, the ability to effortlessly pull multiple heads for the same branch is not key to any project development model I can envision. > Suppose you merge in your gate, and something about the merge goes > horribly wrong -- you end up confused and unsure what bits you've got, > or you seek "help" from someone to merge an arcane area, and he just > makes it worse. > > What will you do? If you do the merge in a child, it's simple: rm -rf > and start over. If you do it in the parent, you're toast. hg rollback. (In my case, I control the child repos too, so I'm not worried about someone else doing a pull of the repo when it was toxic and preventing me from doing a rollback.) -- meem
