Thanks, can you update the wiki page for these changes? I don't have time and yet another deadline looming today...
Much appreciated. -Michelle Stephen Lau wrote: > Richard Lowe wrote: >> michelle olson <michelle.olson at sun.com> writes: >> >>> Hi, >>> >>> I spent some more time on SCMVolunteers genunix page last night. I >>> think I have most of the existing information out there now, in some >>> state of order. Please have a look and let me know what you think. >>> http://www.genunix.org/wiki/index.php/SCMVolunteers >>> >>> Hopefully this will help get you through Monday's KTD with a pointer >>> for folks to reference. Please let them know this is draft content >>> and we encourage their help to improve it :) just CYA for Rao, Venky >>> and me. >>> >>> After we get all the feedback and contributions from others to the >>> content, we can migrate it to the SCM Migration project pages on >>> opensolaris.org. I'll be on vacation Monday and Tuesday, then in BRM >>> rest of the week. >>> >> >> Please don't point people at a random(?) PEF workspace for cadmium. >> I'm not sure where a canoical internal path would be, but it isn't >> that one. The same applies to gpyfm. Also, probably best not to use >> PEF as the example in the hgweb configuration, either. > > +1 > Best would be to tell people to install our SUNWonbld packages I > upload nightly to: > http://dlc.sun.com/osol/scm/SUNWonbld/SUNWonbld-latest.$PLAT.tar.bz2 > and use hgsetup, or point to /opt/onbld for cdm. > > If they want to load something via NFS, they could load from donuthole > (x86) or stomper (sparc) but that will work poorly if they intend to > do any cross platform development and want to use gpyfm/cdm from > multiple machines. > >> 'hg status' is a poor putback -n analogue, as it only shows changes >> you have not yet committed. >> >> putback < comments, is probably best done, in general, with: >> >> hg recommit -fl comments.txt >> >> Rather than expecting the user to have only made one commit. (I think >> the KTD slides cover this). >> >> Resolving conflicts is actually better done with 'hg merge' than >> allowing update to, hg pull, then hg merge. >> >> I'd recommend not even *suggesting* editing hgweb.py. We do not >> suggest users modify files installed by packaging, we shouldn't >> suggest internal users do either. That's better not done, than done >> like that. > > +1 > > cheers, > steve >
