On Wed, Jan 30, 2008 at 03:36:48PM -0500, Richard Lowe wrote: > Dean Roehrich <Dean.Roehrich at sun.com> writes: > > > On Wed, Jan 30, 2008 at 02:24:39PM -0500, Richard Lowe wrote: > >> > Okay, so 'hg commit' will be naked, and won't have a cdm wrapper to make > >> > sure > >> > the commit message is in the correct form (PSARC case, or CR number and > >> > synopsis, on first line). Is this covered by one of the commit hooks? > >> > >> We really don't want to do that on commit, I don't think. > > > > If not on commit, then when? I take it that on/nv users would expect to > > make > > frequent use of cdm_recommit? I'm not real clear on what is happening in > > cdm_recommit...it looks like we're concatenating the log messages for > > several > > changesets and then, what is squishdeltas doing?, maybe an 'hg revert', 'hg > > strip', 'hg commit -A' kind of thing with the new, concatenated, log > > message? > > I can't tell if you're asking about the implementation or its result. > > The result is the same as you would have with 'wx redelget'
Unfortunately, I've never used wx (or cdm, ha!), so I'm struggling to decipher things. > The implementation forces a commit of the current workspace content > over a different prior revision, then removes the prior set of > changes. ...which would give a result similar to revert,strip,commit? If you're not actually doing revert/strip/commit, then are we getting too cozy with Mercurial internals? How difficult will it be for individual people to keep up with Mercurial releases and still use cdm? > I don't think we would want to do comment checks on hg commit, because I agree now, though our reasons differ. I'd like cdm to do it, and I guess you're saying cdm_comchk covers this. But that means there must be a file somewhere that contains the proposed log message, and the user must use 'hg commit -l'. That's fine, and must be what the wx users are doing anyway. > > It's not clear to me, yet, where this enforcement should happen. I think it > > makes sense for cdm to do this, given that the users will be taught to use a > > bunch of cdm commands anyway; if the user had to do it with a commit hook > > then > > what happens when they are working on different projects that require > > different commit hooks (what if people on my team are also working on > > on/nv)? > > The bullet-proofing would have to be on the gate; it would need to do some > > verification, with the ability to abort the incoming push. > > That's precisely what we hope to do (check such things in a gate > hook). I think most projects (ours, included) would probably expect to grab the one being used for on/nv as a template for their own gates. > I'd also like to check them pre-push, but that could cause problems > for projects with different needs, yes. I think I've talked myself out of that idea. It's not bullet-proof, and if it's not bullet-proof then it may as well be handled by cdm, and therefore probably a pointless push-side hg hook. Any hook should be positioned where it will be bullet-proof and won't cause problems when that user is working on other projects, and that means it's on the gate. Dean
