Peter Memishian writes: > > > 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.
Given that one generally _can't_ work inside a project gate hosted on opensolaris.org, which is where I put all of my project gates, I guess I've just not run into anything that fits differently. I don't have internal gates. > 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, You are if we're talking about opensolaris.org repos. ;-} Otherwise, probably not, though I still don't think it's a good practice for anything other than a personal workspace -- where children and multiple heads should be much less of an issue. > > 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.) I've managed to hose things before such that rollback wouldn't get me back to a clean state. (Fortunately, not recently.) It sounds, though, like you *are* worried about ill-timed child pulls. Otherwise, the multiple-head issue would never have come up. Something that hooks on "pretxnchangegroup" and checks for bad pulls might solve it. -- James Carlson, Solaris Networking <james.d.carlson at sun.com> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
