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

-- 
stephen lau // stevel at sun.com | 650.786.0845 | http://whacked.net
opensolaris // solaris kernel development

Reply via email to