Dean Roehrich writes: > On Wed, Jan 30, 2008 at 03:36:48PM -0500, Richard Lowe wrote: > > 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.
Ah, ok. Since it seems you're on the SWAN, try this: man -M /ws/onnv-tools/onbld/man wx > 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'm not sure I understand the issue you're raising, but 'cdm' should be kept in sync with Mercurial as much as is needed. It shouldn't be something that individuals ever have to do ... it's a software dependency (and thus consolidation and distribution) issue between Mercurial and a plug-in module. > 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. It'd be even better to have a common one provided somewhere (such as via ON, but possibly elsewhere) that can be customized via configuration files. The whole grab-a-copy-and-hack-away model is for the birds. It produces a real mess as the tools are upgraded. I hope we don't do that. > > 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. Final checks should be on the gate, as you say, but giving the end developer tools to make nice clean changes in the first place (rather than bashing his head against a recalcitrant gate) is the point of "wx" and the cdm extensions. -- 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
