ÑûÇ뺯
Title: ÐÜèÎÀÊ¿·´²¡¶¾£¬Ò»Âíµ±ÏÈ£¡ ¡¡Èô²»ÄÜÕý³£ä¯ÀÀ´ËÓʼþ£¬Çëµ¥»÷ÕâÀï Ñû¡¡Çë¡¡º¯ Ç×°®µÄÅóÓÑ£¬ 2002ÄêÂíÄêÒÁʼ£¬·À²¡¶¾Êг¡µÄÖ÷Á¦¾ü¹ú¼ÊÖøÃûµÄ¼ÆËã»ú°²È«²úÆ·Èí¼þ¹«Ë¾ÐÜèÈí¼þЯ ͬȫÇòÐÂÆ· Panda Antivirus Enterprise Suite(PAES)ºÍPanda Perimeter Scan (PPS)¡£ÆëÁ¦Óë¹úÄÚ·½Õý¿Æ¼¼ÆìÏÂרӪÈí ¼þÒµÎñµÄ·½ÕýÈí¼þÈ«ÃæºÏ×÷£¬Ò»Âíµ±ÏȵضáµÃÁËÄê³õºÃʱ»ú£¬²¢Óû´òÔì2002ÄêÈí¼þ½çÐÂÆæ¼£¡£½ìʱ£¬ ÐÜèºÍ·½Õý½«³ÏÖ¿ÑûÇëÄúÀ´²Î¼ÓÐÜèÎÀÊ¿ºÍ·½Õý¾«ÐÄΪÄú×¼±¸µÄÉϺ£¡¢±±¾©Á½µØºÏ×÷¼ô²ÊÒÇʽ ôßÈ«ÇòÐÂÆ··¢²¼¡£Ê±¼ä·Ö±ð¶¨ÓÚ2002Äê3ÔÂ26ÈÕ¡¢3ÔÂ29ÈÕ,»¶ÓÄú½ìʱ¹âÁÙ¡£Í¬Ê±£¬ÐÜèºÍ·½Õý½«Æô¶¯ È«¹úÊ®¸ö³ÇÊеÄƽ̨£¬À´·¢ÆðÒ»´Îºìºì»ð»ðµÄÐÂƷչʾÍòÀïÐС£ÐÜèÎÀÊ¿ÄÜÑûÇëµ½Äú½«ÊÇÎÒÃǵÄÈÙÐÒ ¡£ÌرðµÄʱ¼ä£¬ÌرðµÄµØµã£¬ÆÚ´ý×ÅÌرðµÄÄ㣬Çë°ÑÕâ¸öʱ¼ä±£Áô¸øÎÒÃÇ°É¡£ ÎÒÃǽ«ÔÚÉϺ£(3.26)£¬±±¾©(3.29)£¬¹ãÖÝ(4.2)£¬ºþÄÏ(4.15)£¬ÄϾ©(4.19)£¬º¼ÖÝ(4.16)£¬Î÷°²(4.26)£¬ ³É¶¼(4.23)£¬ÉòÑô(4.12)£¬¼ÃÄÏ(4.9)µÈ´ýÄúµÄ¹âÁÙ£¡ ͬʱ£¬¸ÐлÄú¼°¹ó¹«Ë¾Ò»Ö±ÒÔÀ´¶ÔÐÜèÈí¼þµÄÖ§³ÖºÍÐÅÀµ¡£ ÐÜèÈí¼þ£¨Öйú£©ÓÐÏÞ¹«Ë¾ ÉϺ£Õ¹»á£º ʱ¼ä£º2002Äê3ÔÂ26ÈÕ µØµã£ºÉϺ£ÊÐÆÖ¶«ÊÀ¼Í´óµÀ88ºÅ½ðï´óÏà ¡¡½ðï½ðÔôó¾Æµê£¨Èº·¿£©¶þÂ¥Ñç»áÌü¢òÇø ±±¾©Õ¹»á£º ʱ¼ä£º2002Äê3ÔÂ29ÈÕ µØµã£º±±¾©Êк£µíÇøÖª´ºÂ·76ºÅ´ä¹¬·¹µê¶þÂ¥¶à¹¦ÄÜÌü At Panda Software we respect your privacy. If you do not want to receive further communications, click here. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
»¶Ó¹âÁÙÁªÃËÍøÕ¾£££££££££££
Title: »¶Ó¹âÁÙÁªÃËÍøÕ¾ µØÖ·(Add.)£º¶Ø»ÍÊÐÑô¹ØÎ÷·18ºÅ¡¡ÓÊÕþ±àÂ룺736200 µç»°(Tel.)£º+86-0937-8836058 0937-8823155-8266 ´«Õ棺0937-8841337¡¡E-mail£º [EMAIL PROTECTED]
»¶Ó¹âÁÙÁªÃËÍøÕ¾£££££££££££
Title: »¶Ó¹âÁÙÁªÃËÍøÕ¾ µØÖ·(Add.)£º¶Ø»ÍÊÐÑô¹ØÎ÷·18ºÅ¡¡ÓÊÕþ±àÂ룺736200 µç»°(Tel.)£º+86-0937-8836058 0937-8823155-8266 ´«Õ棺0937-8841337¡¡E-mail£º [EMAIL PROTECTED]
»¶Ó¹âÁÙÁªÃËÍøÕ¾£££££££££££
Title: »¶Ó¹âÁÙÁªÃËÍøÕ¾ µØÖ·(Add.)£º¶Ø»ÍÊÐÑô¹ØÎ÷·18ºÅ¡¡ÓÊÕþ±àÂ룺736200 µç»°(Tel.)£º+86-0937-8836058 0937-8823155-8266 ´«Õ棺0937-8841337¡¡E-mail£º [EMAIL PROTECTED]
数字中国（GIS、GPS、RS）国际会议
2002±±¾©¹ú¼Ê3S£¨GIS¡¢GPS¡¢RS£©¼¼ÊõÑÐÌÖôßչʾ»á The 2rd Beijing International 3S Technical Symposium & The 4rd Beijing International GIS Symposium and Exhibition »áÒéµØµã£º±±¾©Î÷½¼±ö¹Ý£¨º£µíÇøÎåµÀ¿ÚÍõׯ·18ºÅ£© ±¨µ½Ê±¼ä£º2002Äê4ÔÂ1ÈÕ ²¼Õ¹Ê±¼ä£º4ÔÂ1ÈÕ »áÒéÕ¹ÀÀʱ¼ä£º4ÔÂ2ÈÕ¡ª 4ÈÕ À뿪ʱ¼ä£º4ÔÂ5ÈÕÉÏÎç 3SµÄÓ¦ÓÃÇ°¾°£ºÔÚδÀ´¼¸ÄêÄÚ£¬µØÀí¿Õ¼äÐÅÏ¢(3S)½«ÊµÏÖËæʱ(anytime)ËæµØ(anywhere)ΪËùÓеÄÈË(anybody)ºÍÊÂ(anything)Ìṩʵʱ·þÎñ(4A·þÎñ)¡£ É3SµÄ´«Í³Ó¦Óà ¿ªÍØ3SеÄÓ¦Óà ÓÃÐÂ˼·½¨ÉèÊý×Ö³ÇÊÐ È«ÃæÌáÉýÖйúÐÅÏ¢»¯Ë®Æ½ ÈëÊÀ¼°Éê°Â³É¹¦½«È«ÃæÌáÉýÊý×ÖÖйú½¨Éè ÑûÇ뺯 ÄúÄÜÏëÏóÔÚ²»¾ÃµÄ½«À´£¨Ò²Ðí¾ÍÔÚÃ÷Ä꣩£¬ÄúÖ»ÐèÒªÒ»¸öÊÖ»ú¡¢Ò»¿é±í»òÆäËüËæÉíСÎï¼þ¾Í¿ÉÒÔ׼ȷ¶¨Î»ÓÚ¸ßÂ¥´óÏÃÖ®¼ä»ò´Ôɽ¾þÁëÖ®µß£¬ÏíÊÜ3S¼¼Êõ´øÀ´µÄȫй¤×÷ÓëÉú»î±ãÀû£¿ ÄúΪÄúµ¥Î»ÐÅÏ¢»¯Ë®Æ½µÍ¡¢Ê¼ÖÕÕÒ²»µ½·¢Õ¹Ö®Â·¶øÀ§»óÂ𣿽¨Á¢ÍøÕ¾¡¢¼òµ¥µÄµç×ÓÉÌÎñ²»ÊÇÐÅÏ¢»¯Ö®±¾£¬È«ÃæÓ¦ÓÃ3S¼¼Êõ½«Õ¼ÁìÐÅÏ¢¼¼ÊõµÄÖƸߵ㡣 Äúµ¥Î»Îª½«À´µÄ·¢Õ¹×öºÃ×¼±¸ÁËÂð£¿ÔÚÇ¿µ÷¿ì½ÝÓë¸ßЧ·þÎñµÄ½ñÌ죬ÔÚÏû·ÑÕßÔ½À´Ô½Ç¿µ÷·þÎñµÄ½ñÌ죬ÔÚÒ»ÇÐÒÔÓû§²»¶Ï±ä»¯µÄÐèÇóÓë·þÎñΪ¾ÓªÖ®±¾µÄÃ÷Ì죬ÄúÖªµÀ3S½«·¢»ÓʲôÖØÒªµÄ×÷ÓÃÂ𣿠Äú¹«Ë¾ÕÒ²»µ½ÀûÈóÔö³¤µã£¬²»ÖªÖг¤ÆÚ¿ÉÄܳöÏÖµÄÈ«Éç»á¶¼¹Ø×¢²¢ÕùÏàÓ¦ÓõÄм¼ÊõÈȵ㣿ÄÇôÇëÏÖÔÚͶÉí3S¼¼ÊõµÄ¿ª·¢ÓëÓ¦ÓᣠÄú×öºÃ×¼±¸ÓÚ2002Äê3ÔÂ31ÈÕÆð³ÌÀ´±±¾©²Î»áÁËÂ𣿠Ö÷°ìµ¥Î» ²â»æÒ£¸ÐÐÅÏ¢¹¤³Ì¹ú¼ÒÖصãʵÑéÊÒ ÖпÆÔº×ÊÔ´Óë»·¾³ÐÅϢϵͳ¹ú¼ÒÖصãʵÑéÊÒ ¹ú¼ÒÒ£¸ÐÓ¦Óù¤³Ì¼¼ÊõÑо¿ÖÐÐÄ ¹ú¼ÒGPSÓ¦Óù¤³Ì¼¼ÊõÑо¿ÖÐÐÄ ±±¾©´óѧң¸ÐÓëGISÑо¿Ëù Öйúº£ÍâµØÀíÐÅÏ¢ÏµÍ³Ð»á ¹ú¼ÊÉãÓ°²âÁ¿ÓëÒ£¸Ðлá°îÁªÊý¾Ý¿âÓ뻥²Ù×÷¹¤×÷×é ¹ú¼ÊÉãÓ°²âÁ¿ÓëÒ£¸Ðлá¿Õ¼äÊý¾Ý¹ÜÀí¼¯³Éϵͳ¹¤×÷×é Ö§³Öµ¥Î» ¹ú¼ÒÏà¹Ø²¿Î¯ÐÅÏ¢ÖÐÐÄ ²¿·ÖÊ¡ÊÐÐÅÏ¢°ì Ïà¹Ø¹æ»®²â»æÔºµÈÊ®¼¸¼Òµ¥Î» ³Ð°ìµ¥Î» ±±¾©Ã÷ÈÕ²ÊÔƹã¸æÓÐÏÞ¹«Ë¾ ÌرðÖ§³ÖýÌå ¡¶3SÊÀ½ç¡· ÄúÁ˽â3SÈçºÎÌáÉý´«Í³ÐÐÒµÂ𣿠ÄúÀ´×ÔÓÚ×ÔÀ´Ë®¡¢µçÁ¦¡¢ÃºÆøµÈÐÐÒµ£¬ÄúÖªµÀGISÈçºÎ¿ì½Ý׼ȷ¶¨Î»¹ÜµÀ¡¢¹ÜÏß¹ÊÕÏÂð£¿ÄúÖªµÀ3SÈçºÎ×ö¹ÜÏßÑ¡ÐÍÓÅ»¯£¬¸üÓÐЧÌá¸ß¹ÜÀíÄÜÁ¦Â𣿠ÄúÀ´×ÔÓÚ¹úÍÁ¡¢½»Í¨¡¢Ë®µç¡¢¼Æί¡¢²â»æ¡¢µçÐŵÈÐÐÒµ¹ÜÀí»ú¹Ø£¬ÄúÁ˽â3S¼¼ÊõÏÖÔÚÒÑÈÕÐÂÔÂÒƵط¢Õ¹ÁËÂð£¿ÄúÖªµÀ²ÉÓÃ3S¼¼Êõ½«²úÉúʲô±ä»¯Â𣿠ÄúÀ´×Ô3S´«Í³Ó¦Óõĵؿ󡢿±Ì½µÈ²¿ÃÅ£¬ÄúÁ˽â3SµÄ¸üÐÂÌæ´ú²úÆ·¡¢×îз¢Õ¹ÏÖ×´¼°ÈçºÎ½â¾öÄúʹÓÃÖеÄÎÊÌâÂ𣿠ֻÓи÷µ¥Î»¸÷ÐÐÒµÆëÐÄÐÁ¦£¬Êý×ÖÖйú½¨Éè²Å²»½ö½öÊǿںš£ Äúµ¥Î»ÍÏÑÓÖйúÊý×Ö»¯½¨ÉèµÄ½ø³ÌÁËÂ𣿠¸üйÛÄ´ÓÏÖÔÚ×öÆð£¬Âõ¿ªÒ»²½º£À«Ìì¿Õ¡£ ¿ìÀ´±¨Ãû²Î»á°É£¬±¾´Î»áÕ¹´ø¸øÄúµÄ²»½ö½öÊÇѧϰÓë½»Á÷¡£ 3SÇé¿ö½éÉÜ Êý×ÖµØÇòµÄ¸ÅÄîÊÇËÄÄêÇ°ÓÉÃÀ¹úÇ°¸±×Üͳ¸ê¶ûÌá³öµÄ¡£Êý×ÖµØÇòÖ÷ÒªÖ¸Ó¦ÓõØÀíÐÅϢϵͳ£¨GIS£©¡¢È«Çò¶¨Î»ÏµÍ³£¨GPS£©¡¢Ò£¸Ð£¨RS£©µÈ¼¼Êõ£¬ÒÔÊý×ֵķ½Ê½»ñÈ¡¡¢´¦ÀíºÍÓ¦ÓùØÓÚµØÇò×ÔÈ»ºÍÈËÎÄÒòËصĿռäÊý¾Ý£¬²¢ÔÚ´Ë»ù´¡ÉϽâ¾öÈ«Çò¸÷ÖÖÎÊÌâ¡£Èç½ñ£¬ÐÅÏ¢¼¼Êõ¸ïÃüϯ¾íÈ«Çò£¬Ê¹ÈËÀà¶ÔµØÇò¿Õ¼äÊý¾Ý½øÐд¦Àí¡¢·ÖÎöµÄ¼¼ÊõÊֶκ͹ÛÄî·¢ÉúÁË·Ì츲µØµÄ±ä»¯¡£ÔÚÕâÖÖÇé¿öÏ£¬ÈËÃÇ¿ÉÒÔ°ÑÓйصØÇòµÄ´óÁ¿µÄ¡¢¶à·Ö±æÂʵġ¢ÈýάµÄ¡¢¶¯Ì¬µÄÊý¾Ý°´µØÀí×ø±ê¼¯³ÉÆðÀ´£¬ÐγÉÒ»¸öÊý×ÖµØÇò¡£½èÖúÓÚÕâ¸öÊý×ÖµØÇò£¬ÈËÃÇÎÞÂÛ×ßµ½ÄÄÀ¶¼¿ÉÒÔ°´µØÀí×ø±êÁ˽âµØÇòÉÏÈκÎÒ»´¦¡¢Èκη½ÃæµÄÐÅÏ¢¡£Êý×ÖµØÇòÊǶÔÕæʵµØÇò¼°ÆäÏà¹ØÏÖÏóͳһÐÔµÄÊý×Ö»¯ÖØÏÖºÍÈÏʶ£¬ºËÐÄ˼ÏëÓÐÁ½µã£ºÒ»ÊÇÓÃÊý×Ö»¯ÊÖ¶ÎͳһµØ´¦ÀíµØÇòÎÊÌ⣻¶þÊÇ×î´óÏ޶ȵØÀûÓÃÐÅÏ¢×ÊÔ´¡£Êý×ÖµØÇòÓÉÏÂÁÐÌåϵ¹¹³É£ºÊý¾Ý»ñÈ¡Óë¸üÐÂÌåϵ¡¢Êý¾Ý´¦ÀíÓë´æ´¢Ìåϵ¡¢ÐÅÏ¢ÌáÈ¡Óë·ÖÎöÌåϵ¡¢Êý¾ÝÓëÐÅÏ¢´«²¥Ìåϵ¡¢Êý¾Ý¿âÌåϵ¡¢ÍøÂçÌåϵ¡¢×¨ÓÃÈí¼þÌåϵµÈ¡£Êý×ÖµØÇò¿ÉÒÔ°üÈÝ80£¥ÒÔÉϵÄÈËÀàÐÅÏ¢×ÊÔ´£¬ÊÇδÀ´ÐÅÏ¢×ÊÔ´µÄÖ÷ÌåºËÐÄ¡£ ½ü¼¸ÄêÀ´£¬È«ÇòÊý×Ö»¯È¡µÃÁËÍ»·ÉÃͽøµÄ·¢Õ¹¡£ÔÚÈ«ÇòÐÅÏ¢Êý×Ö»¯µÄʵʩ¹ý³ÌÖУ¬µØÇò¿Õ¼äÐÅÏ¢¼¼Êõ£¨3S,¼´GIS¡¢GPS¡¢RS£©Æð×ÅÊ®·ÖÖØÒªµÄ×÷Óã¬GIS¡¢RS¡¢GPSµÄ¼¯³É¹¹¼ÜÁËÊý×ÖµØÇò¡£1999Äê11ÔÂ19ÈÕ£¬ÔÚ±±¾©ÕÙ¿ªÁË¡°Êý×ÖµØÇò¹ú¼Ê»áÒ顱£¬ Àîá°Ç帱×ÜÀíÔÚ»áÉÏÌá³ö£¬Öйú½«Á¦ÕùÔÚÊý×ÖµØÇò½¨ÉèÖÐʵÏÖ¿çԽʽ·¢Õ¹¡£ µØÀíÐÅϢϵͳ£¨Geographical Information System,GIS£©Êǽü¶þÊ®ÄêÀ´·¢Õ¹ÆðÀ´µÄÒ»ÃÅ×ÛºÏÓ¦ÓÃϵͳ£¬ËüÄܰѸ÷ÖÖÐÅϢͬµØÀíλÖúÍÓйصÄÊÓͼ½áºÏÆðÀ´£¬²¢°ÑµØÀíѧ¡¢¼¸ºÎѧ¡¢¼ÆËã»ú¿Æѧ¼°¸÷ÖÖÓ¦ÓöÔÏó¡¢Internet¡¢¶àýÌå¼¼Êõ¼°ÐéÄâÏÖʵ¼¼ÊõµÈÈÚΪһÌ壬ÀûÓüÆËã»úͼÐÎÓëÊý¾Ý¿â¼¼ÊõÀ´²É¼¯¡¢´æ´¢¡¢±à¼¡¢ÏÔʾ¡¢×ª»»¡¢·ÖÎöºÍÊä³öµØÀíͼÐμ°ÆäÊôÐÔÊý¾Ý¡£ÕâÑù£¬¾Í¿É¸ù¾ÝÓû§ÐèÒª½«ÕâЩÐÅϢͼÎIJ¢Ã¯µØÊäË͸øÓû§£¬±ãÓÚʹÓᣠȫÇò¶¨Î»ÏµÍ³£¨Global Positioning System,GPS£©ÊÇÉÏÊÀ¼Í70Äê´úÓÉÃÀ¹ú¹ú·À²¿Åú×¼£¬Â½º£¿ÕÈý¾üÁªºÏÑÐÖƵÄÐÂÒ»´ú¿Õ¼äÎÀÐǵ¼º½¶¨Î»ÏµÍ³¡£ÆäÖ÷ҪĿµÄÊÇΪ½¡¢º£¡¢¿ÕÈý´óÁìÓòÌṩʵʱ¡¢È«ÌìºòºÍÈ«ÇòÐԵĵ¼º½·þÎñ¡£È«Çò¶¨Î»ÏµÍ³¹²ÓÉÈý²¿·Ö¹¹³É£ºµØÃæ¿ØÖƲ¿·Ö¡¢¿Õ¼ä²¿·Ö¡¢Óû§×°Öò¿·ÖµÈ¡£GPSµÄÖ÷ÒªÌصãÊÇÈ«Ììºò¡¢È«Çò¸²¸Ç¡¢Èýά¶¨ËÙ¶¨Ê±¸ß¾«¶È¡¢¿ìËÙʡʱ¸ßЧÂʼ°Ó¦Óù㷺¶à¹¦ÄÜ¡£ Ò£¸Ð(Remote Sensing,RS)£¬¹ËÃû˼Ò壬¾ÍÊÇÒ£Ô¶µØ¸ÐÖª¡£ÈËÀàͨ¹ý´óÁ¿µÄʵ¼ù£¬·¢ÏÖµØÇòÉÏÿһ¸öÎïÌ嶼ÔÚ²»Í£µØÎüÊÕ¡¢·¢ÉäºÍ·´ÉäÐÅÏ¢ºÍÄÜÁ¿£¬ÆäÖÐÓÐÒ»ÖÖÈËÀàÒѾÈÏʶµ½µÄÐÎʽ¡ª¡ªµç´Å²¨£¬²¢ÇÒ·¢ÏÖ²»Í¬ÎïÌåµÄµç´Å²¨ÌØÐÔÊDz»Í¬µÄ¡£Ò£¸Ð¾ÍÊǸù¾ÝÕâ¸öÔÀíÀ´Ì½²âµØ±íÎïÌå¶Ôµç´Å²¨µÄ·´ÉäºÍÆä·¢ÉäµÄµç´Å²¨£¬´Ó¶øÌáÈ¡ÕâЩÎïÌåµÄÐÅÏ¢£¬Íê³ÉÔ¶¾àÀëʶ±ðÎïÌå¡£ Ò£¸ÐµÄʵÏÖ»¹ÐèÒªÒ£¸Ðƽ̨£¬ÏñÎÀÐÇ¡¢·É»ú¡¢ÆøÇòµÈ£¬ËüÃǵÄ×÷ÓþÍÊÇÎȶ¨µØÔËÔØ´«¸ÐÆ÷¡£µ±ÔÚµØÃæÊÔÑéʱ£¬»¹»áÓõ½µØÃæÏóÈý½Ç¼ÜÕâÑù¼òµ¥µÄÒ£¸Ðƽ̨¡£Õë¶Ô²»Í¬µÄÓ¦ÓúͲ¨¶Î·¶Î§£¬ÈËÃÇÒѾÑо¿³öºÜ¶à
Re: New member and new to CVS
> Has CVS ever been used in a client/server environment that > includes NT boxes (Windows 2000), and may or may not include a Unix > box? > Yes. We use a Linux CVS server with primarily Windows clients. There are some unix clients but they are in the minority. There is also an NT based CVS server but I have no experience with it. Mike ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
»¶Ó¹âÁÙÁªÃËÍøÕ¾£££££££££££
Title: »¶Ó¹âÁÙÁªÃËÍøÕ¾ µØÖ·(Add.)£º¶Ø»ÍÊÐÑô¹ØÎ÷·18ºÅ¡¡ÓÊÕþ±àÂ룺736200 µç»°(Tel.)£º+86-0937-8836058 0937-8823155-8266 ´«Õ棺0937-8841337¡¡E-mail£º [EMAIL PROTECTED]
»¶Ó¹âÁÙÁªÃËÍøÕ¾£££££££££££
Title: »¶Ó¹âÁÙÁªÃËÍøÕ¾ µØÖ·(Add.)£º¶Ø»ÍÊÐÑô¹ØÎ÷·18ºÅ¡¡ÓÊÕþ±àÂ룺736200 µç»°(Tel.)£º+86-0937-8836058 0937-8823155-8266 ´«Õ棺0937-8841337¡¡E-mail£º [EMAIL PROTECTED]
»¶Ó¹âÁÙÁªÃËÍøÕ¾£££££££££££
Title: »¶Ó¹âÁÙÁªÃËÍøÕ¾ µØÖ·(Add.)£º¶Ø»ÍÊÐÑô¹ØÎ÷·18ºÅ¡¡ÓÊÕþ±àÂ룺736200 µç»°(Tel.)£º+86-0937-8836058 0937-8823155-8266 ´«Õ棺0937-8841337¡¡E-mail£º [EMAIL PROTECTED]
»¶Ó¹âÁÙÁªÃËÍøÕ¾£££££££££££
Title: »¶Ó¹âÁÙÁªÃËÍøÕ¾ µØÖ·(Add.)£º¶Ø»ÍÊÐÑô¹ØÎ÷·18ºÅ¡¡ÓÊÕþ±àÂ룺736200 µç»°(Tel.)£º+86-0937-8836058 0937-8823155-8266 ´«Õ棺0937-8841337¡¡E-mail£º [EMAIL PROTECTED]
»¶Ó¹âÁÙÁªÃËÍøÕ¾£££££££££££
Title: »¶Ó¹âÁÙÁªÃËÍøÕ¾ µØÖ·(Add.)£º¶Ø»ÍÊÐÑô¹ØÎ÷·18ºÅ¡¡ÓÊÕþ±àÂ룺736200 µç»°(Tel.)£º+86-0937-8836058 0937-8823155-8266 ´«Õ棺0937-8841337¡¡E-mail£º [EMAIL PROTECTED]
Cannot use taginfo file
hello, i've tried to use the taginfo file to be alerted by mail when a user creates a tag. But it seems that this functionnality doesn't work. I tried to put into taginfo this line : (PS : This command is also stored into loginfo and comit. and that's work for these files) ALL (echo "To: [EMAIL PROTECTED]"; echo "Subject: tag created"; echo; cat) | /usr/lib/sendmail -t When i try to create a tag, i receive this message : cvs server: cannot exec (echo: No such file or directory cvs server: Pre-tag check failed cvs [server aborted]: correct the above errors first! Version of CVS : Client: Concurrent Versions System (CVS) 1.11.1 (client/server) Server: Concurrent Versions System (CVS) 1.11.1 (client/server) Thanks for your help. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
»¶Ó¹âÁÙÁªÃËÍøÕ¾£££££££££££
Title: »¶Ó¹âÁÙÁªÃËÍøÕ¾ µØÖ·(Add.)£º¶Ø»ÍÊÐÑô¹ØÎ÷·18ºÅ¡¡ÓÊÕþ±àÂ룺736200 µç»°(Tel.)£º+86-0937-8836058 0937-8823155-8266 ´«Õ棺0937-8841337¡¡E-mail£º [EMAIL PROTECTED]
ChemNet.com合并Chemyahoo.com推出全球化工网！
Title: Chemnet.com ChemNet.com×ÔÓëµÂ¹úBuyersGuideChem.de¡¢°Ä´óÀûÑÇChemlink .com.au³É¹¦ºÏ×÷ºó£¬ÈÕÇ°ÓÖÉÏÈ«ÇòÕ½ÂÔÐĄ̂½×£¬ÓÚ2ÔÂ28ÈÕÕýʽºÏ²¢È«Çò×î´óµÄ»¯¹¤Êý¾Ý¿â¼°ËÑË÷ÒýÇæChemyahoo.com£¬Â¡ÖØÍƳö¼¯Ò»Á÷µÄÐÅÏ¢Ìṩ¡¢¶¥¼¶×¨ÒµËÑË÷ÒýÇæ¡¢ÐÂÒ»´úB2B½»Ò×ϵͳΪһÌåµÄ"È«Çò»¯¹¤ÃÅ»§"¡£ ºÏ²¢ºó½«Ê¹ÓÃChemnet.comÆ·ÅÆ£¬ÔChemyahoo.comÓû§¿ÉÔÚChemnet.comÉϼÌÐøÏíÊÜÆäÔÏàÓ¦·þÎñ¡£ChemNet.com½«Ç¿Á¦Íƶ¯È«Çò»¯¹¤ÆóÒµ¿ªÍعú¼ÊóÒס£ ÊÀ ½ç »¯ ¹¤ ÃÅ »§ , ¹ú ¼Ê ÉÌ Ã³ ͨ µÀ ! È«Çò»¯¹¤Íø£¨www.chemnet.com£©ÊÇÊÀ½çÊ×Ñ¡µÄ»¯¹¤ÃÅ»§ÍøÕ¾¡£Ëü¼¯È«Çò»¯¹¤ÍøÂçÐÅÏ¢Óëµç×ÓÉÌÎñÖ®´ó³É£¬½«ÊÀ½çÒ»Á÷µÄÐÅÏ¢Ìṩ¡¢ËÑË÷ÒýÇæ¡¢½»Ò×ϵͳºÏΪһÌ壬ΪȫÇò»¯¹¤¿ÍÉÌÌṩÁË׿ԽµÄÔÚÏßÉÌóƽ̨¡£ ÍøÕ¾ÓÅÊÆ www.chemnet.comÒÔÆäÌØÊâµÄÀúÊ·Ô¨Ô´ºÍÈ«ÇòÓ°ÏìÁ¦£¬¼®ÊÀ½çÁìÏȵÄB2B½»Ò×ϵͳ¡¢×¨ÒµÒýÇæºÍÐÅÏ¢×ÊÔ´£¬ÎªÄúÌṩÎ޿ɱÈÄâµÄÉÌÒµÏÈ»ú-- 1£®www.chemnet.comÓòÃûÓÐÁùÄêÀúÊ·£¬ÖÜתÊÀ½çËÄ´óÖÞÁù¸ö¹ú¼ÒÃûÂúÈ«Çò 2£®ºÏ²¢È«Çò×î´óµÄ»¯¹¤Êý¾Ý¿â¼°ÒýÇæChemyahoo.com£¬ÍƳö¶¥¼¶×¨ÒµÄ¿Â¼ÒýÇæ 3£®Í¬ÃÀ¹ú¡¢µÂ¹ú¡¢º«¹ú¡¢ÈÕ±¾¡¢°Ä´óÀûÑǵȻ¯¹¤ÍøÕ¾½áÃËΪ"È«Çò»¯¹¤¹²Í¬Ìå" 4£®ÄÚÖùúÄÚÊ×´´¡¢¹ú¼ÊÁìÏÈ£¬¸Äд´«Í³½»Ò×·½Ê½µÄÐÂÒ»´úÕæÕýB2B½»Ò×ϵͳ 5£®¹úÄÚ»¯¹¤ÃÅ»§Öйú»¯¹¤ÍøÇãÁ¦Í¶È룬ºÏÁ¦´òͨ»¥¶¯È«ÇòµÄóÒ×ͨµÀ ÖªÃû¶È ¹ú¼Ê£ºChemNetÊÇÓÉÓ¢ÎÄchemical(»¯¹¤)network£¨ÍøÂ磩¼ò³Æ×éºÏ¶øÀ´£¬¹«ÈÏÓÐÖ±¹ÛµÄ"»¯¹¤Íø"µÄÒâ˼,ÊÇ»¯¹¤ÍøÂç½çµÄȨÍþÓòÃû¡£ www.chemnet.comµ®ÉúÓÚ1995Äê2ÔÂ,ÏȺóÖÜתÃÀ¹ú¡¢Ó¡¶È¡¢ Èðµä¡¢°Ä´óÀûÑÇ¡¢º«¹ú¡¢ÖйúËÄ´óÖÞÁù¸ö¹ú¼Ò£¬ÃûÂúÈ«Çò¡£ÒÔ¸ÃÓòÃû¼ÓÉÏÆäËû¹ú¼Ò»òµØÇøÓòÃûºó׺µÄÑÜÉúÓòÃû¹¹½¨µÄƽ̨¾ÍÓÐ100¶à¸ö£¬Á´½Ó±é²¼È«Çò¸÷´óËÑË÷ÒýÇæºÍ»¯¹¤ÉÌÒµ¡¢¿ÆÑС¢½ÌÓýµÈ»ú¹¹£¬ÎªÈ«ÇòµÄ»¯¹¤¿ÍÉÌËùÊìÖª¡£ ¹úÄÚ£ºÖйú»¯¹¤ÍøÔÚ¿ç¹ú¹Ù˾Öл÷°Ü°Ä´óÀûÑÇ×î´óµÄ»¯¹¤¼¯ÍÅORICA¹«Ë¾£¬Ó®µÃÎÒ¹úÈëÊÀ¿ç¹ú֪ʶ²úȨ¾À·×µÚÒ»°¸£¬ Áî¼ÛֵǧÍòÃÀ½ðµÄÓòÃûwww.chemnet.comÂ仧Öйú£¬²¢ÔÚ´ËÓòÃûÏ´´½¨ÁËÊÀ½çÊ×Ñ¡µÄ»¯¹¤ÃÅ»§ÍøÕ¾£¬³ÉΪÈËÃñÈÕ±¨¡¢CCTV¡¢Ð»ªÉç¡¢Öйú¹ú¼Ê¹ã²¥µç̨¡¢ÖÐÐÂÉç¡¢ÖйúÈÕ±¨¡¢Ïã¸ÛÎĻ㱨¡¢½â·ÅÈÕ±¨¡¢Öйú»¯¹¤±¨¡¢ÑÅ»¢¡¢ÐÂÀË¡¢ËѺüµÈÖ÷Á÷ýÌå¹Ø×¢µÄ½¹µã,£¬400¶à¼ÒýÌå²ÎÓ뱨µÀ£¬¾Ù¹úÖõÄ¿¡£ Ö÷ÒªÀ¸Ä¿ 1£®»¯¹¤Ä¿Â¼(Directory) 2£®½»Ò×ÖÐÐÄ(Exchange) 3£®Êý¾Ý¿â(Suppliers) 4£®Ã³Ò×»ú»á(Trade Leads) 5£®Õ¹»áÐÅÏ¢(Expo) 6£®»¯¹¤×Öµä(Dictionary) ׿Խ·þÎñ È«Çò»¯¹¤Íø׿ԽµÄ·þÎñÆ·ÖÊÌåÏÖÔÚÆ䳬Խ³£¹æµÄ·þÎñÀíÄî--Ϊ»¯¹¤Óû§´òÔìÈ«Çò»¯µÄÐÐÒµÃÅ»§¡¢ÓªÔì¹ú¼Ê»¯µÄÉÌó»·¾³¡¢ÌṩÁìÏÈÊÀ½çµÄ½»Ò×ϵͳ¡£ 1£® ΪÆóÒµËÜÔì¹ú¼ÊÐÎÏó¡¢Ê÷Á¢¹ú¼ÊÆ·ÅÆÌṩ¿ì½Ý¡¢ÓÐЧµÄ;¾¶¡£ 2£® ƽ̨±é²¼È«ÇòµÄ·ÃÎÊÕß¼°ºÏ×÷»ï°éÓªÔìÒ»Á÷µÄ¹ú¼Ê»¯ÉÌó»·¾³ 3£® ƽ̨µÄ½»Ò×ϵͳ£¨Exchange£©ÌṩÐÂÒ»´úÍêÉƸßЧµÄµç×ÓÉÌÎñ½â¾ö·½°¸¡£ ·þÎñÏîÄ¿ È«Çò»¯¹¤Íøwww.chemnet.comÔÚÖйú´ó½ĿǰÖ÷ÒªÌṩ"¾²Ì¬¹ã¸æ"¡¢"¹Ø¼ü×Ö¹ã¸æ"¡¢"Öйú¹©Ó¦ÉÌ"ºÍ"Ãâ·Ñ¶þ¼¶ÓòÃû×¢²á"ËÄÏî·þÎñ¡£ »¯¹¤ÃÅ»§--ÐÐÒµÐÅÏ¢¾¡À¿ÑÛµ×£¡ ÒÔÉÌΪ±¾--ÖúÄú¿ªÍØÈ«ÇòÉÌ»ú£¡ º¼ÖÝÖл¯ÍøÂçÓÐÏÞ¹«Ë¾ ¡¡Tel:0086-571-88868638¡¡ Fax:0086-571-88868972
旌轎渣昫腔俋籀羲阹源宒
Title: ±ÜÃâ´íÎóµÄÍâó¿ªÍØ·½Ê½ ÍâÏú½Óµ¥ÆäʵºÜ¼òµ¥£¬ÎÊÌâÊÇ . ¡¡ ÄãËù²ÉÓõķ½·¨£¬ ÊǶԵģ¿»¹ÊÇ´íµÄ£¿ ÍØÕ¹Íâó ¹ó¹«Ë¾ÊÇ·ñÒ»ÈçÍùÎô£¿¯µÇÔÓÖ¾¹ã¸æ»ò²Î¼ÓÉÌÆ·Õ¹ÀÀ£¿ ±»¶¯µÄµÈ¿Í»§¿´µ½Äú¿¯µÇµÄ¹ã¸æ£¿µÈ¿Í»§µ½Äú²ÎÕ¹µÄ̯λ²Î¹Û£¿ ÊÇ·ñ¸Ð¾õЧÄÜÈÕÒæµÍÂ䣿£¿ÒòΪ¹ú¼ÊóÒ×´ó»·¾³¸Ä±äÁË£¡ "¹ú¼ÊóÒ×ÁªÑ¶Íø"ÔËÓÃרҵ¼° È«·½Î»ÎªÄúÍØÕ¹ÍâóÊг¡ ΪÄú²¼ÏÂ"ÌìÂÞµØÍø"ÍøסÂò¼Ò ¡¡ ¹ú¼ÊóÒ×ÁªÑ¶Íø Ò¼¡¢ÓµÓÐ×î·á¸»µÄÊý¾Ý¿â : 1¡¢ÓµÓÐÈ«Çò50¶àÍò¼Ò½ø¿ÚÉÌ×ÊÁÏ 2¡¢ÓÐÈ«Çò3Íò¶à±Ê¿Í»§ÊµÊ±¹ºÂòÉÌ»ú 3¡¢ÓÐÀà·ÖÏîµÄ½ø¿Ú³§ÉÌ¿ìËÙ²éѯ ·¡¡¢×î¿ìËٵĿª·¢¹ú¼ÊÊг¡£¬Ð§¹ûÈà Äú¾ªÑÈ£º ÔËÓ÷ḻµÄÊý¾Ý¿â¼°¸ß¿Æ¼¼Ö®¼¼Êõ£¬ÎÒÃÇÌæ»áÔ±²éѯȫÇòÂòÖ÷(½ø¿ÚÉÌ ) ²¢´úΪE-mailÓÚÂò·½£¬³ÉЧ¿ìËÙ£¬¶©µ¥½Ó Á¬¶øÀ´¡£ ²Î¡¢×îÈ«ÃæµÄÈ«ÇòÍøÂç¹ã¸æÈÃÈ˲»µÃ ²»¿´µ½Äú£º ¹ã¸æµÄµÚÒ»ÒªÎñÊÇÒªÈÃÂò·½Äܹ»¿´µ½ÄúµÄ¹«Ë¾Óë²úÆ·£¬µ«Òª´ï´ËЧ¹û £¬Í¨³£Òª»¨·Ñ¾Þ×Ê·½¿ÉÄÜÈçÔ¸¡£¹ú¼ÊóÒ×ÁªÑ¶ÍøµÄÓŻݹ¤³Ìʦ£¬Ó¦ÓÃÑз¢ ¼¼Êõ£¬ÎªÄú¿Ë·þÀ§ÄÑ¡£ÎÒÃÇ°ï»áÔ±Á¬½áÈ«ÇòÖªÃûËÑÑ°ÒýÇæ¼°²¼¸æÀ¸³¬¹ý 9000¼Ò£¬Ê¹µÃÂò¼ÒÉÏÍø²»µÃ²»¿´µ½Äú£¬µ±È» Ôö¼ÓÁ˽»Ò׵ĿÉÄÜÐÔ£¬¶©µ¥×ÔȻԴԴ¶øÀ´¡£ ¹ú¼ÊóÒ×ÁªÑ¶ÍøʸÖÁ³ÉΪ ¹ú¼Ê´óóÒ×ÐÅÏ¢Íø²¢³ÉΪ»áÔ±¹«Ë¾µÄÍâ󿪷¢²¿ÃÅΪ¶¨Î»¡£ ÊÂʵ֤Ã÷¼ÓÈëµÄ»áÔ±Ò²Òò´ËÒµÎñÅ·¢Õ¹£¬¿Í»§¼±ËÙÔö¼Ó£¬¶©µ¥´óÁ¿ Ôö¼Ó¶øÍò·ÖÐË·Ü£¬Ã¿Î»»áÔ±½Ô³ÆÒâÏë²»µ½£¡ ÎÒÃdzÏÖ¿µÄÇëÄú¼ÓÈë 0315ר°¸ ÒÔ5.5ÕÛ ÓÅ»ÝлáÔ± Ç°50Ãû²¢Ãâ·ÑÔùËÍÌæ»áÔ±²éѯÂò·½²¢E-mailÓÚ½ø¿ÚÉÌ (Ω±¾°¸ÓÅ´ýÆÚ ÖÁ±¾Äê3ÔÂ15ÈÕ½ØÖ¹) Ç°100Ãû£¬ мÓÈë»áÔ±£¨°ëÄ꣬һÄê¼°¶þÄ꣩ÔùËÍ´úËÑÑ°E-MAIL ÓÚÏà¶Ô½ø¿ÚÉÌ£¬¶þÄêVIP »áÔ±ÁíÔùÁ¬½áÈ«ÇòËÑÑ°ÒýÇæ²¼¸æÀ¸³¬¹ý9000¼Ò£¬ ʹµÃ±ðÈ˲»µÃ²»¿´µ½Äú¡±Á¢¼´¼ÓÈ롱¹ú¼ÊóÒ×ÁªÑ¶Íø¡±¼´¿ÌÈÃÄú½Ó±¶Êý ³É³¤£¡£¡£¡ ÌÈÓû½øÒ»²½Á˽âÇë°´=£¾ http://www.ezlink.com.tw/ ²Î¹Û¡£ÎÒÃÇÔËÓÃËÄÖÖÓïÎÄÀ´·½±ãÈ«Çò¸÷µØ »áԱʹÓ㬻òÀ´µç:86(020)38850406»áÔ±·þÎñÖÐÐÄ Ç¢Ñ¯ Èñ¾ÏîÄ¿³ÉΪ¹ú¼ÊóÒ×ÁªÑ¶ÍøΪÄú·þÎñµÄ¿ªÊ¼¡£ ¹ú¼ÊóÒ×ÁªÑ¶Íø ¡¡EZLink Internation Trade net ´ó½µç»°:86(020)38850406 E-MAIL£º[EMAIL PROTECTED] ̨Íåµç»°:(02)23456-929 ÃÀ¹úµç»° :(1)765-497-3937 Ïã¸Ûµç»° :(852)29153221 E-MAIL£º[EMAIL PROTECTED] E-MAIL:[EMAIL PROTECTED] E-MAIL£º[EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Get diff between two releases
Hello ! I would like to know if it is possible to get only the changed files between two releases (two different tags) in order to give a patch as small as possible. Thanks a lot Regards Eric Gambardella ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
»¶Ó¹âÁÙÁªÃËÍøÕ¾£££££££££££
Title: »¶Ó¹âÁÙÁªÃËÍøÕ¾ µØÖ·(Add.)£º¶Ø»ÍÊÐÑô¹ØÎ÷·18ºÅ¡¡ÓÊÕþ±àÂ룺736200 µç»°(Tel.)£º+86-0937-8836058 0937-8823155-8266 ´«Õ棺0937-8841337¡¡E-mail£º [EMAIL PROTECTED]
»¶Ó¹âÁÙÁªÃËÍøÕ¾£££££££££££
Title: »¶Ó¹âÁÙÁªÃËÍøÕ¾ µØÖ·(Add.)£º¶Ø»ÍÊÐÑô¹ØÎ÷·18ºÅ¡¡ÓÊÕþ±àÂ룺736200 µç»°(Tel.)£º+86-0937-8836058 0937-8823155-8266 ´«Õ棺0937-8841337¡¡E-mail£º [EMAIL PROTECTED]
»¶Ó¹âÁÙÁªÃËÍøÕ¾£££££££££££
Title: »¶Ó¹âÁÙÁªÃËÍøÕ¾ µØÖ·(Add.)£º¶Ø»ÍÊÐÑô¹ØÎ÷·18ºÅ¡¡ÓÊÕþ±àÂ룺736200 µç»°(Tel.)£º+86-0937-8836058 0937-8823155-8266 ´«Õ棺0937-8841337¡¡E-mail£º [EMAIL PROTECTED]
»¶Ó¹âÁÙÁªÃËÍøÕ¾£££££££££££
Title: »¶Ó¹âÁÙÁªÃËÍøÕ¾ µØÖ·(Add.)£º¶Ø»ÍÊÐÑô¹ØÎ÷·18ºÅ¡¡ÓÊÕþ±àÂ룺736200 µç»°(Tel.)£º+86-0937-8836058 0937-8823155-8266 ´«Õ棺0937-8841337¡¡E-mail£º [EMAIL PROTECTED]
»¶Ó¹âÁÙÁªÃËÍøÕ¾£££££££££££
Title: »¶Ó¹âÁÙÁªÃËÍøÕ¾ µØÖ·(Add.)£º¶Ø»ÍÊÐÑô¹ØÎ÷·18ºÅ¡¡ÓÊÕþ±àÂ룺736200 µç»°(Tel.)£º+86-0937-8836058 0937-8823155-8266 ´«Õ棺0937-8841337¡¡E-mail£º [EMAIL PROTECTED]
»¶Ó¹âÁÙÁªÃËÍøÕ¾£££££££££££
Title: »¶Ó¹âÁÙÁªÃËÍøÕ¾ µØÖ·(Add.)£º¶Ø»ÍÊÐÑô¹ØÎ÷·18ºÅ¡¡ÓÊÕþ±àÂ룺736200 µç»°(Tel.)£º+86-0937-8836058 0937-8823155-8266 ´«Õ棺0937-8841337¡¡E-mail£º [EMAIL PROTECTED]
Õý°æÈí¼þ×¢²áÂëÃâ·Ñ·¢ËÍ
ÄúºÃ£¡ »¶ÓʹÓÃʤÐÂÏÖ´ú°ì¹«¹ÜÀíϵÁÐÈí¼þ ʤÐÂÏÖ´ú°ì¹«¹ÜÀíϵÁÐÈí¼þÊÇÒ»Ì×¼¯¼Æ»®¡¢²Ö¿â¡¢ÈËÊ¡¢½øÏú´æ¡¢ ¹Ì¶¨×ʲú¡¢³öÄÉ¡¢Éú²úµÈÆóÒµ¹ÜÀí¸÷¸ö»·½ÚµÄ¹ÜÀíϵÁÐÈí¼þ¡£Èí¼þ¹¦ ÄÜÇ¿´ó¡¢²Ù×÷¼ò±ã¡¢ÊÊÓÃÓë¸÷Àà´ó¡¢ÖС¢Ð¡ÐÍÆóÒµ¼°ÊÂÒµµ¥Î»£¬Óû§ ȺÌ帲¸ÇÈ«¹ú¸÷µØ¡¢¸÷Ðи÷Òµ¡£ËùÓÐÈí¼þ¾ù¿ÉÌṩµ¥»ú°æ¼°ÍøÂç°æ¡£ ƾ´ËÓʼþÃâ·Ñ»ñµÃ¡¶Ê¤ÐÂͨÓÃÐÅ·â´òӡϵͳ¡·Õý°æ×¢²áÂëÒ»¸ö£¬¼Û Öµ88Ôª£¬ÇëÏÈÏÂÔز¢°²×°Èí¼þ£¬ÉêÇë×¢²áÂëʱÇëÌṩÈí¼þÏÂÔØ°²×°ºóµÄ ÐòÁкţ¬ÐòÁкż°ÓÊÏäµØÖ·ÔÚÈí¼þÖеİæȨÐÅÏ¢ÖпÉÒԲ鵽¡£ ËùÓÐÈí¼þ¾ùÌṩÃâ·ÑÏÂÔØÊÔÓ㬻¶Ó·ÃÎÊʤÐÂÈí¼þÍøÕ¾ÏÂÔØÈí¼þ£º ʤÐÂÈí¼þÍøÕ¾ÍøÖ·£º http://www.sx188.com Äú¿ÉÒÔÏÂÔØÊÔÓÃÏÂÁÐÈí¼þ£º ¡¶Ê¤Ð¿â¹ÜÍõ¡·¹¦ÄÜÇ¿´ó£¬¼ò±ãÒ×ÓõIJֿ⼰»õÆ·¹ÜÀíÈí¼þ¡£ ¡¶Ê¤ÐÂͨÓÃÈËʹ¤×ʹÜÀíϵͳºÀ»ª°æ¡·¹¦ÄÜÍêÉÆ£¬²Ù×÷¼ò±ã£¬ÄÒÀ¨ ÈËʼ°¹¤×ʹÜÀíµÄ·½·½ÃæÃ棬ÔËÐÐÎȶ¨£¬Ê®·Ö³©Ïú¡£ ¡¶Ê¤Ð½øÏú´æ2000¡·ÄÒÀ¨ÆóÒµ²É¹º¹ÜÀí¡¢²Ö¿â¹ÜÀí¡¢ÏúÊÛ¹ÜÀí¡¢Ó¦ ÊÕ¿î¹ÜÀí¡¢Ó¦¸¶¿î¹ÜÀíµÈÆóÒµ¹ÜÀí¸÷»·½Ú£¬ÌṩÉÏ°ÙÖÖ±¨±í¡£ ¡¶Ê¤Ð³öÄÉ-֧Ʊ´òÓ¡Èí¼þ¡·ÀûÓÃÆÕͨ´òӡ֧Ʊ£¬·½±ã׼ȷ£¬»¹¿ÉÒÔ ¹ÜÀí×ʽð½ø³ö¼°ÕÊÎñϵͳ¡£ ¡¶Ê¤ÐÂͨÓù̶¨×ʲú¹ÜÀíϵͳ¡·µ¥Î»¹Ì¶¨×ʲú¼°É豸µÈ¹ÜÀíµÄºÃ°ïÊÖ¡£ ¡¶Ê¤ÐÂͨÓÃÆóÒµ¼Æ»®¹ÜÀíϵͳ¡·°üÀ¨ÆóÒµÔËÓªÖеIJɹº¡¢Éú²ú¡¢ÏúÊÛ¡¢ ×ʽ𡢹¤×Ê¡¢Í¶×ʵȸ÷·½Ãæ¼Æ»®¹ÜÀí¡£ ¡¶Ê¤ÐÂͨÓÃÐÅ·â´òӡϵͳµä¡··½±ã´òÓ¡¸÷ÖÖ±ê×¼Ðŷ⣬·½±ã£¬Ö§³ÖÅú Á¿ÐÅ·â´òÓ¡£¬ÊǸöÈË´¦ÀíÐź¯¼°µ¥Î»´¦ÀíÐź¯µÄºÃ°ïÊÖ¡£ ¡¶Ê¤ÐÂÏÖ´ú°ì¹«°Ù±¦Ïä¡·ÌṩÃûƬ¹ÜÀí¡¢ÍøÖ·¹ÜÀí¡¢Ô±¹¤¹ÜÀí¡¢¿¼ÇÚ ¹ÜÀí¡¢ÌìÆø×´¿ö¹ÜÀí¡¢Òµ¼¨¹ÜÀíµÈʹÓð칫¹ÜÀí¹¤¾ß¡£ ʤÐÂÈí¼þÍøÖ·£º http://www.sx188.com <<---ÒÔÉÏÓʼþÄÚÈÝÓëÖÐ×ÊÔ´ÍøÂç¼°Èí¼þ×÷ÕßÎÞ¹Ø--->> ÖÐ×ÊÔ´ÍøÂç--ÓòÃûÏÈ×¢²áºó¸¶¿î;Ö÷»úÏÈ¿ªÍ¨ºóÊÕ·Ñ¡£ ÉêÇë100MÐéÄâÖ÷»ú350Ôª/Ä꣬Ë͹ú¼ÊÓòÃû+5¸öÐÅÏä http://www.163asp.net ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: (Win)CVS guide for VSS users
Hi, I use jcvs, "export" command works as get latest version of VSS. However I dont know this command exist in wincvs (but most probably exist) In wincvs "checkout" command works like get latest version, different from vss (in vss they checkout command assign file for user but in wincvs it is not.) Gul Colak --- Andreas Koch <[EMAIL PROTECTED]> wrote: > Hi, > > i have WinCVS up and running, but still can't > handle it > I am used to the handling of MS VSS, so is > there any WinCVS user guide (or command line > CVS user guide, if that makes things easier) > for VSS-users? > > My current problem: get-all-files-of-project- > overwrite-all-existing-ones-wheter-changed-or > -not > > In VSS, this would just be > right click project/get latest version > /include subdirectories/ok > > How to do this with (Win)CVS ? > > > -- >Andreas > To spam me by mail, please add NOSPAM to my > email address. > > ___ > Info-cvs mailing list > [EMAIL PROTECTED] > http://mail.gnu.org/mailman/listinfo/info-cvs __ Do You Yahoo!? Try FREE Yahoo! Mail - the world's greatest free email! http://mail.yahoo.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
ÑûÇ뺯
Title: ÐÜèÎÀÊ¿·´²¡¶¾£¬Ò»Âíµ±ÏÈ£¡ ¡¡Èô²»ÄÜÕý³£ä¯ÀÀ´ËÓʼþ£¬Çëµ¥»÷ÕâÀï Ñû¡¡Çë¡¡º¯ Ç×°®µÄÅóÓÑ£¬ 2002ÄêÂíÄêÒÁʼ£¬·À²¡¶¾Êг¡µÄÖ÷Á¦¾ü¹ú¼ÊÖøÃûµÄ¼ÆËã»ú°²È«²úÆ·Èí¼þ¹«Ë¾ÐÜèÈí¼þЯ ͬȫÇòÐÂÆ· Panda Antivirus Enterprise Suite(PAES)ºÍPanda Perimeter Scan (PPS)¡£ÆëÁ¦Óë¹úÄÚ·½Õý¿Æ¼¼ÆìÏÂרӪÈí ¼þÒµÎñµÄ·½ÕýÈí¼þÈ«ÃæºÏ×÷£¬Ò»Âíµ±ÏȵضáµÃÁËÄê³õºÃʱ»ú£¬²¢Óû´òÔì2002ÄêÈí¼þ½çÐÂÆæ¼£¡£½ìʱ£¬ ÐÜèºÍ·½Õý½«³ÏÖ¿ÑûÇëÄúÀ´²Î¼ÓÐÜèÎÀÊ¿ºÍ·½Õý¾«ÐÄΪÄú×¼±¸µÄÉϺ£¡¢±±¾©Á½µØºÏ×÷¼ô²ÊÒÇʽ ôßÈ«ÇòÐÂÆ··¢²¼¡£Ê±¼ä·Ö±ð¶¨ÓÚ2002Äê3ÔÂ26ÈÕ¡¢3ÔÂ29ÈÕ,»¶ÓÄú½ìʱ¹âÁÙ¡£Í¬Ê±£¬ÐÜèºÍ·½Õý½«Æô¶¯ È«¹úÊ®¸ö³ÇÊеÄƽ̨£¬À´·¢ÆðÒ»´Îºìºì»ð»ðµÄÐÂƷչʾÍòÀïÐС£ÐÜèÎÀÊ¿ÄÜÑûÇëµ½Äú½«ÊÇÎÒÃǵÄÈÙÐÒ ¡£ÌرðµÄʱ¼ä£¬ÌرðµÄµØµã£¬ÆÚ´ý×ÅÌرðµÄÄ㣬Çë°ÑÕâ¸öʱ¼ä±£Áô¸øÎÒÃÇ°É¡£ ÎÒÃǽ«ÔÚÉϺ£(3.26)£¬±±¾©(3.29)£¬¹ãÖÝ(4.2)£¬ºþÄÏ(4.15)£¬ÄϾ©(4.19)£¬º¼ÖÝ(4.16)£¬Î÷°²(4.26)£¬ ³É¶¼(4.23)£¬ÉòÑô(4.12)£¬¼ÃÄÏ(4.9)µÈ´ýÄúµÄ¹âÁÙ£¡ ͬʱ£¬¸ÐлÄú¼°¹ó¹«Ë¾Ò»Ö±ÒÔÀ´¶ÔÐÜèÈí¼þµÄÖ§³ÖºÍÐÅÀµ¡£ ÐÜèÈí¼þ£¨Öйú£©ÓÐÏÞ¹«Ë¾ ÉϺ£Õ¹»á£º ʱ¼ä£º2002Äê3ÔÂ26ÈÕ µØµã£ºÉϺ£ÊÐÆÖ¶«ÊÀ¼Í´óµÀ88ºÅ½ðï´óÏà ¡¡½ðï½ðÔôó¾Æµê£¨Èº·¿£©¶þÂ¥Ñç»áÌü¢òÇø ±±¾©Õ¹»á£º ʱ¼ä£º2002Äê3ÔÂ29ÈÕ µØµã£º±±¾©Êк£µíÇøÖª´ºÂ·76ºÅ´ä¹¬·¹µê¶þÂ¥¶à¹¦ÄÜÌü At Panda Software we respect your privacy. If you do not want to receive further communications, click here. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
ÑûÇ뺯
ÐÜèÎÀÊ¿·´²¡¶¾£¬Ò»Âíµ±ÏÈ£¡
.txt {
FONT-SIZE: 12px; FONT-STYLE: normal; FONT-FAMILY: Verdana, Arial, Helvetica,
sans-serif
}
.txtnegro {
FONT-SIZE: 11px; COLOR: #ff; LINE-HEIGHT: normal; FONT-FAMILY: Arial,
Helvetica, sans-serif
}
.titular {
FONT-WEIGHT: bold; FONT-SIZE: 10pt; FONT-FAMILY: Verdana, Arial, Helvetica,
sans-serif
}
¡¡Èô²»ÄÜÕý³£ä¯ÀÀ´ËÓʼþ£¬Çëµ¥»÷http://www.pandaguard.com/newpanda/markting200203/invite.htm";
target="_blank">͉˕
http://www.pandaguard.com/newpanda/markting200203/invite/spacer.gif";
width=58>
http://www.pandaguard.com/newpanda/markting200203/invite/spacer.gif";
width=109>
http://www.pandaguard.com/newpanda/markting200203/invite/spacer.gif";
width=198>
http://www.pandaguard.com/newpanda/markting200203/invite/spacer.gif";
width=232>
http://www.pandaguard.com/newpanda/markting200203/invite/spacer.gif";
width=183>
http://www.pandaguard.com/newpanda/markting200203/invite/homee_01.gif";
width=58>
http://www.pandaguard.com/newpanda/markting200203/image/logo_txt.gif"; width="508"
height="49">
http://www.pandaguard.com/newpanda/markting200203/invite/spacer.gif";
width=1>
http://www.pandaguard.com/newpanda/markting200203/invite/homee_03.gif";
colSpan=4 rowSpan=2>
Ñû¡¡Çë¡¡º¯
Ç×°®µÄÅóÓÑ£¬
2002ÄêÂíÄêÒÁʼ£¬·À²¡¶¾Êг¡µÄÖ÷Á¦¾ü¹ú¼ÊÖøÃûµÄ¼ÆËã»ú°²È«²úÆ·Èí¼þ¹«Ë¾http://www.pandaguard.com/newpanda/aboutus/pandaguard.htm"; target="_blank">ÐÜèÈí¼þЯ
ͬȫÇòÐÂÆ·
http://www.pandaguard.com/newpanda/markting200203/paes.htm";>Panda
Antivirus
Enterprise Suite(PAES)ºÍhttp://www.pandaguard.com/newpanda/markting200203/pps.htm";>Panda
Perimeter Scan (PPS)¡£ÆëÁ¦Óë¹úÄÚ·½Õý¿Æ¼¼ÆìÏÂרӪÈí
¼þÒµÎñµÄ·½ÕýÈí¼þÈ«ÃæºÏ×÷£¬Ò»Âíµ±ÏȵضáµÃÁËÄê³õºÃʱ»ú£¬²¢Óû´òÔì2002ÄêÈí¼þ½çÐÂÆæ¼£¡£½ìʱ£¬
ÐÜèºÍ·½Õý½«³ÏÖ¿ÑûÇë¼°Áìµ¼À´²Î¼ÓÐÜèÎÀÊ¿ºÍ·½Õý¾«ÐÄΪÄú×¼±¸µÄÉϺ£¡¢±±¾©Á½µØºÏ×÷¼ô²ÊÒÇʽ
ôßÈ«ÇòÐÂÆ··¢²¼¡£Ê±¼ä·Ö±ð¶¨ÓÚ2002Äê3ÔÂ26ÈÕ¡¢3ÔÂ29ÈÕ,»¶ÓÄú½ìʱ¹âÁÙ¡£Í¬Ê±£¬ÐÜèºÍ·½Õý½«Æô¶¯
È«¹úÊ®¸ö³ÇÊеÄƽ̨£¬À´·¢ÆðÒ»´Îºìºì»ð»ðµÄÐÂƷչʾÍòÀïÐС£ÐÜèÎÀÊ¿ÄÜÑûÇëµ½Äú½«ÊÇÎÒÃǵÄÈÙÐÒ
¡£ÌرðµÄʱ¼ä£¬ÌرðµÄµØµã£¬ÆÚ´ý×ÅÌرðµÄÄ㣬Çë°ÑÕâ¸öʱ¼ä±£Áô¸øÎÒÃÇ°É¡£
ÎÒÃǽ«ÔÚÉϺ£(3.26)£¬±±¾©(3.29)£¬¹ãÖÝ(4.2)£¬ºþÄÏ(4.15)£¬ÄϾ©(4.19)£¬º¼ÖÝ(4.16)£¬Î÷°²(4.26)£¬
³É¶¼(4.23)£¬ÉòÑô(4.12)£¬¼ÃÄÏ(4.9)µÈ´ýÄúµÄ¹âÁÙ£¡
ͬʱ£¬¸ÐлÄú¼°¹ó¹«Ë¾Ò»Ö±ÒÔÀ´¶ÔÐÜèÈí¼þµÄÖ§³ÖºÍÐÅÀµ¡£
http://www.pandaguard.com";
target="_blank">ÐÜèÈí¼þ£¨Öйú£©ÓÐÏÞ¹«Ë¾
http://www.pandaguard.com/";>http://www.pandaguard.com/newpanda/markting200203/image/logo_txt1.gif";
width="247" height="120" align="top" border="0"
alt="·é»ðÉñÖÝ">
ÉϺ£Õ¹»á£º
ʱ¼ä£º2002Äê3ÔÂ26ÈÕ
µØµã£ºÉϺ£ÊÐÆÖ¶«ÊÀ¼Í´óµÀ88ºÅ½ðï´óÏÃ
¡¡½ðï½ðÔôó¾Æµê£¨Èº·¿£©¶þÂ¥Ñç»áÌü¢òÇø
±±¾©Õ¹»á£º
ʱ¼ä£º2002Äê3ÔÂ29ÈÕ
µØµã£º±±¾©Êк£µíÇøÖª´ºÂ·76ºÅ´ä¹¬·¹µê¶þÂ¥¶à¹¦ÄÜÌü
http://www.pandaguard.com/newpanda/markting200203/paes.htm";>http://www.pandaguard.com/newpanda/markting200203/image/ensuite.gif"; width="183"
height="216" border="0" alt="ÐÜè×îÐÂÆó
Òµ·À²¡¶¾Ì××°" align="top">
http://www.pandaguard.com/newpanda/markting200203/invite/spacer.gif";
width=1>
http://www.pandaguard.com/newpanda/markting200203/pps.htm";>http://www.pandaguard.com/newpanda/markting200203/image/perimeterscan.gif";
width="183" height="213" border="0"
align="top" alt="ÐÜèÈí¼þ PerimeterScan£¬ÄúµÄµÚÒ»µÀ·ÀÏߣ¡">
http://www.pandaguard.com/newpanda/markting200203/invite/spacer.gif";
width=1>
http://www.pandaguard.com/newpanda/markting200203/feedback.htm";>http://www.pandaguard.com/newpanda/markting200203/invite/homee_06.gif";
width=167 border=0 alt="Ìîд»ØÖ´">
http://www.pandaguard.com/newpanda/markting200203/product.htm";>http://www.pandaguard.com/newpanda/markting200203/invite/homee_07.gif";
width=198 border=0 alt="²úÆ·ÐÅÏ¢">
http://www.pandaguard.com/";>http://www.pandaguard.com/newpanda/markting200203/in
Re: CVS and Jar files: Should you import Jar into the Repository? Why or why not
> "Noel" == Noel Yap <[EMAIL PROTECTED]> writes:
Noel> --- Lee Sau Dan <[EMAIL PROTECTED]>
Noel> wrote:
>> My credit card is also designed to server a very very specific
>> purpose. But when I can't a ruler nearby and I need one, why
>> not use that plastic object from purse as a ruler?
Noel> I'm assuming you mean a straight-edge, not a ruler?
Isn't a ruler for drawing rules, i.e. straing lines?
Noel> Actually, this brings up an even better analogy: A ruler is
Noel> meant to measure things, not as a straight-edge.
I've never seen any "ruler" that does not provide a straight edge.
Noel> There are text formats that aren't easily mergable (eg XML)
It depends on what tools you use to edit the XML files.
Noel> and binary formats that can be mergable (eg Word).
B'cos the data encoded inside is just text in nature.
Noel> Or, more likely, well enough for your needs. Since XML
Noel> isn't the typical linear text format (ie it's hierarchical),
Noel> diff3 isn't the ideal three-way diff tool to use.
Why not? Pascal programs, for instance, are highly hierarchical. But
they should (I've never tried) work well with CVS.
--
Lee Sau Dan §õ¦u´°(Big5)~{@nJX6X~}(HZ)
E-mail: [EMAIL PROTECTED]
Home page: http://www.informatik.uni-freiburg.de/~danlee
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS and Jar files: Should you import Jar into the Repository? Why or why not
> "Christian" == Christian Andersson <[EMAIL PROTECTED]> writes:
Christian> Hmm diff/merge, one short question, as you might have
Christian> understood Linux/unix and it's tools are not my main
Christian> expertise .-)
Christian> Does not linux come with a diff-tool?
"diff" has been a *standard* utility program on all Unices for decades.
Christian> Is not that difftool used by cvs?
I think CVS handles the trivial cases itself, and delegates the
difficult cases to "diff".
Christian> If so, if you have 2 full versions of the same file on
Christian> the harddisk and run this difftool would not the output
Christian> of that difftool be the same as what cvs will give you?
Other than a few addition lines printed by CVS indicating the revision
numbers being diff'ed, the result is the same.
Christian> in the end, you can still use diff/merge even without
Christian> cvs,
Yes. And we have 'patch' to do the merge. There's also diff3.
Christian> however cvs does this for you, and it keeps the
Christian> files smaller on the harddisc...
More importantly, it knows which diff-result to apply to which
revision. And it handles branching and tagging.
--
Lee Sau Dan §õ¦u´°(Big5)~{@nJX6X~}(HZ)
E-mail: [EMAIL PROTECTED]
Home page: http://www.informatik.uni-freiburg.de/~danlee
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS and Jar files: Should you import Jar into the Repository? Why or why not
> "Greg" == Greg A Woods <[EMAIL PROTECTED]> writes:
>> Not necessarily. I don't know your background, but the Unix
>> mentality is to have a bunch of tools that do one thing
>> extremely well and are easily integrated into one another.
Greg> Another way of saying this is that M$-Windows programmers
Greg> tend to speak in individual words which they hope each
Greg> convey a great deal of meaning.
And this is because their grammar is very simple and limited.
Basically, this grammar only allows sentences of a length of one word.
They are thus reluctant to learn to speak longer sentences, which are
foreign to them.
Greg> Unix programmers on the other hand speak in sentences, and
Greg> each sentence is made up of small and usually simple words
Greg> which are flexible and which may have a different meaning
Greg> depeneding on their context. The result is that Unix
Greg> programmers can say one heck of a lot more using a much
Greg> smaller, and thus much easier to use, set of words.
And of course, this is supported by a highly expressive and flexible
grammar.
--
Lee Sau Dan §õ¦u´°(Big5)~{@nJX6X~}(HZ)
E-mail: [EMAIL PROTECTED]
Home page: http://www.informatik.uni-freiburg.de/~danlee
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
数字中国（GIS、GPS、RS）国际会议
2002±±¾©¹ú¼Ê3S£¨GIS¡¢GPS¡¢RS£©¼¼ÊõÑÐÌÖôßչʾ»á The 2rd Beijing International 3S Technical Symposium & The 4rd Beijing International GIS Symposium and Exhibition »áÒéµØµã£º±±¾©Î÷½¼±ö¹Ý£¨º£µíÇøÎåµÀ¿ÚÍõׯ·18ºÅ£© ±¨µ½Ê±¼ä£º2002Äê4ÔÂ1ÈÕ ²¼Õ¹Ê±¼ä£º4ÔÂ1ÈÕ »áÒéÕ¹ÀÀʱ¼ä£º4ÔÂ2ÈÕ¡ª 4ÈÕ À뿪ʱ¼ä£º4ÔÂ5ÈÕÉÏÎç 3SµÄÓ¦ÓÃÇ°¾°£ºÔÚδÀ´¼¸ÄêÄÚ£¬µØÀí¿Õ¼äÐÅÏ¢(3S)½«ÊµÏÖËæʱ(anytime)ËæµØ(anywhere)ΪËùÓеÄÈË(anybody)ºÍÊÂ(anything)Ìṩʵʱ·þÎñ(4A·þÎñ)¡£ É3SµÄ´«Í³Ó¦Óà ¿ªÍØ3SеÄÓ¦Óà ÓÃÐÂ˼·½¨ÉèÊý×Ö³ÇÊÐ È«ÃæÌáÉýÖйúÐÅÏ¢»¯Ë®Æ½ ÈëÊÀ¼°Éê°Â³É¹¦½«È«ÃæÌáÉýÊý×ÖÖйú½¨Éè ÑûÇ뺯 ÄúÄÜÏëÏóÔÚ²»¾ÃµÄ½«À´£¨Ò²Ðí¾ÍÔÚÃ÷Ä꣩£¬ÄúÖ»ÐèÒªÒ»¸öÊÖ»ú¡¢Ò»¿é±í»òÆäËüËæÉíСÎï¼þ¾Í¿ÉÒÔ׼ȷ¶¨Î»ÓÚ¸ßÂ¥´óÏÃÖ®¼ä»ò´Ôɽ¾þÁëÖ®µß£¬ÏíÊÜ3S¼¼Êõ´øÀ´µÄȫй¤×÷ÓëÉú»î±ãÀû£¿ ÄúΪÄúµ¥Î»ÐÅÏ¢»¯Ë®Æ½µÍ¡¢Ê¼ÖÕÕÒ²»µ½·¢Õ¹Ö®Â·¶øÀ§»óÂ𣿽¨Á¢ÍøÕ¾¡¢¼òµ¥µÄµç×ÓÉÌÎñ²»ÊÇÐÅÏ¢»¯Ö®±¾£¬È«ÃæÓ¦ÓÃ3S¼¼Êõ½«Õ¼ÁìÐÅÏ¢¼¼ÊõµÄÖƸߵ㡣 Äúµ¥Î»Îª½«À´µÄ·¢Õ¹×öºÃ×¼±¸ÁËÂð£¿ÔÚÇ¿µ÷¿ì½ÝÓë¸ßЧ·þÎñµÄ½ñÌ죬ÔÚÏû·ÑÕßÔ½À´Ô½Ç¿µ÷·þÎñµÄ½ñÌ죬ÔÚÒ»ÇÐÒÔÓû§²»¶Ï±ä»¯µÄÐèÇóÓë·þÎñΪ¾ÓªÖ®±¾µÄÃ÷Ì죬ÄúÖªµÀ3S½«·¢»ÓʲôÖØÒªµÄ×÷ÓÃÂ𣿠Äú¹«Ë¾ÕÒ²»µ½ÀûÈóÔö³¤µã£¬²»ÖªÖг¤ÆÚ¿ÉÄܳöÏÖµÄÈ«Éç»á¶¼¹Ø×¢²¢ÕùÏàÓ¦ÓõÄм¼ÊõÈȵ㣿ÄÇôÇëÏÖÔÚͶÉí3S¼¼ÊõµÄ¿ª·¢ÓëÓ¦ÓᣠÄú×öºÃ×¼±¸ÓÚ2002Äê3ÔÂ31ÈÕÆð³ÌÀ´±±¾©²Î»áÁËÂ𣿠Ö÷°ìµ¥Î» ²â»æÒ£¸ÐÐÅÏ¢¹¤³Ì¹ú¼ÒÖصãʵÑéÊÒ ÖпÆÔº×ÊÔ´Óë»·¾³ÐÅϢϵͳ¹ú¼ÒÖصãʵÑéÊÒ ¹ú¼ÒÒ£¸ÐÓ¦Óù¤³Ì¼¼ÊõÑо¿ÖÐÐÄ ¹ú¼ÒGPSÓ¦Óù¤³Ì¼¼ÊõÑо¿ÖÐÐÄ ±±¾©´óѧң¸ÐÓëGISÑо¿Ëù Öйúº£ÍâµØÀíÐÅÏ¢ÏµÍ³Ð»á ¹ú¼ÊÉãÓ°²âÁ¿ÓëÒ£¸Ðлá°îÁªÊý¾Ý¿âÓ뻥²Ù×÷¹¤×÷×é ¹ú¼ÊÉãÓ°²âÁ¿ÓëÒ£¸Ðлá¿Õ¼äÊý¾Ý¹ÜÀí¼¯³Éϵͳ¹¤×÷×é Ö§³Öµ¥Î» ¹ú¼ÒÏà¹Ø²¿Î¯ÐÅÏ¢ÖÐÐÄ ²¿·ÖÊ¡ÊÐÐÅÏ¢°ì Ïà¹Ø¹æ»®²â»æÔºµÈÊ®¼¸¼Òµ¥Î» ³Ð°ìµ¥Î» ±±¾©Ã÷ÈÕ²ÊÔƹã¸æÓÐÏÞ¹«Ë¾ ÌرðÖ§³ÖýÌå ¡¶3SÊÀ½ç¡· ÄúÁ˽â3SÈçºÎÌáÉý´«Í³ÐÐÒµÂ𣿠ÄúÀ´×ÔÓÚ×ÔÀ´Ë®¡¢µçÁ¦¡¢ÃºÆøµÈÐÐÒµ£¬ÄúÖªµÀGISÈçºÎ¿ì½Ý׼ȷ¶¨Î»¹ÜµÀ¡¢¹ÜÏß¹ÊÕÏÂð£¿ÄúÖªµÀ3SÈçºÎ×ö¹ÜÏßÑ¡ÐÍÓÅ»¯£¬¸üÓÐЧÌá¸ß¹ÜÀíÄÜÁ¦Â𣿠ÄúÀ´×ÔÓÚ¹úÍÁ¡¢½»Í¨¡¢Ë®µç¡¢¼Æί¡¢²â»æ¡¢µçÐŵÈÐÐÒµ¹ÜÀí»ú¹Ø£¬ÄúÁ˽â3S¼¼ÊõÏÖÔÚÒÑÈÕÐÂÔÂÒƵط¢Õ¹ÁËÂð£¿ÄúÖªµÀ²ÉÓÃ3S¼¼Êõ½«²úÉúʲô±ä»¯Â𣿠ÄúÀ´×Ô3S´«Í³Ó¦Óõĵؿ󡢿±Ì½µÈ²¿ÃÅ£¬ÄúÁ˽â3SµÄ¸üÐÂÌæ´ú²úÆ·¡¢×îз¢Õ¹ÏÖ×´¼°ÈçºÎ½â¾öÄúʹÓÃÖеÄÎÊÌâÂ𣿠ֻÓи÷µ¥Î»¸÷ÐÐÒµÆëÐÄÐÁ¦£¬Êý×ÖÖйú½¨Éè²Å²»½ö½öÊǿںš£ Äúµ¥Î»ÍÏÑÓÖйúÊý×Ö»¯½¨ÉèµÄ½ø³ÌÁËÂ𣿠¸üйÛÄ´ÓÏÖÔÚ×öÆð£¬Âõ¿ªÒ»²½º£À«Ìì¿Õ¡£ ¿ìÀ´±¨Ãû²Î»á°É£¬±¾´Î»áÕ¹´ø¸øÄúµÄ²»½ö½öÊÇѧϰÓë½»Á÷¡£ 3SÇé¿ö½éÉÜ Êý×ÖµØÇòµÄ¸ÅÄîÊÇËÄÄêÇ°ÓÉÃÀ¹úÇ°¸±×Üͳ¸ê¶ûÌá³öµÄ¡£Êý×ÖµØÇòÖ÷ÒªÖ¸Ó¦ÓõØÀíÐÅϢϵͳ£¨GIS£©¡¢È«Çò¶¨Î»ÏµÍ³£¨GPS£©¡¢Ò£¸Ð£¨RS£©µÈ¼¼Êõ£¬ÒÔÊý×ֵķ½Ê½»ñÈ¡¡¢´¦ÀíºÍÓ¦ÓùØÓÚµØÇò×ÔÈ»ºÍÈËÎÄÒòËصĿռäÊý¾Ý£¬²¢ÔÚ´Ë»ù´¡ÉϽâ¾öÈ«Çò¸÷ÖÖÎÊÌâ¡£Èç½ñ£¬ÐÅÏ¢¼¼Êõ¸ïÃüϯ¾íÈ«Çò£¬Ê¹ÈËÀà¶ÔµØÇò¿Õ¼äÊý¾Ý½øÐд¦Àí¡¢·ÖÎöµÄ¼¼ÊõÊֶκ͹ÛÄî·¢ÉúÁË·Ì츲µØµÄ±ä»¯¡£ÔÚÕâÖÖÇé¿öÏ£¬ÈËÃÇ¿ÉÒÔ°ÑÓйصØÇòµÄ´óÁ¿µÄ¡¢¶à·Ö±æÂʵġ¢ÈýάµÄ¡¢¶¯Ì¬µÄÊý¾Ý°´µØÀí×ø±ê¼¯³ÉÆðÀ´£¬ÐγÉÒ»¸öÊý×ÖµØÇò¡£½èÖúÓÚÕâ¸öÊý×ÖµØÇò£¬ÈËÃÇÎÞÂÛ×ßµ½ÄÄÀ¶¼¿ÉÒÔ°´µØÀí×ø±êÁ˽âµØÇòÉÏÈκÎÒ»´¦¡¢Èκη½ÃæµÄÐÅÏ¢¡£Êý×ÖµØÇòÊǶÔÕæʵµØÇò¼°ÆäÏà¹ØÏÖÏóͳһÐÔµÄÊý×Ö»¯ÖØÏÖºÍÈÏʶ£¬ºËÐÄ˼ÏëÓÐÁ½µã£ºÒ»ÊÇÓÃÊý×Ö»¯ÊÖ¶ÎͳһµØ´¦ÀíµØÇòÎÊÌ⣻¶þÊÇ×î´óÏ޶ȵØÀûÓÃÐÅÏ¢×ÊÔ´¡£Êý×ÖµØÇòÓÉÏÂÁÐÌåϵ¹¹³É£ºÊý¾Ý»ñÈ¡Óë¸üÐÂÌåϵ¡¢Êý¾Ý´¦ÀíÓë´æ´¢Ìåϵ¡¢ÐÅÏ¢ÌáÈ¡Óë·ÖÎöÌåϵ¡¢Êý¾ÝÓëÐÅÏ¢´«²¥Ìåϵ¡¢Êý¾Ý¿âÌåϵ¡¢ÍøÂçÌåϵ¡¢×¨ÓÃÈí¼þÌåϵµÈ¡£Êý×ÖµØÇò¿ÉÒÔ°üÈÝ80£¥ÒÔÉϵÄÈËÀàÐÅÏ¢×ÊÔ´£¬ÊÇδÀ´ÐÅÏ¢×ÊÔ´µÄÖ÷ÌåºËÐÄ¡£ ½ü¼¸ÄêÀ´£¬È«ÇòÊý×Ö»¯È¡µÃÁËÍ»·ÉÃͽøµÄ·¢Õ¹¡£ÔÚÈ«ÇòÐÅÏ¢Êý×Ö»¯µÄʵʩ¹ý³ÌÖУ¬µØÇò¿Õ¼äÐÅÏ¢¼¼Êõ£¨3S,¼´GIS¡¢GPS¡¢RS£©Æð×ÅÊ®·ÖÖØÒªµÄ×÷Óã¬GIS¡¢RS¡¢GPSµÄ¼¯³É¹¹¼ÜÁËÊý×ÖµØÇò¡£1999Äê11ÔÂ19ÈÕ£¬ÔÚ±±¾©ÕÙ¿ªÁË¡°Êý×ÖµØÇò¹ú¼Ê»áÒ顱£¬ Àîá°Ç帱×ÜÀíÔÚ»áÉÏÌá³ö£¬Öйú½«Á¦ÕùÔÚÊý×ÖµØÇò½¨ÉèÖÐʵÏÖ¿çԽʽ·¢Õ¹¡£ µØÀíÐÅϢϵͳ£¨Geographical Information System,GIS£©Êǽü¶þÊ®ÄêÀ´·¢Õ¹ÆðÀ´µÄÒ»ÃÅ×ÛºÏÓ¦ÓÃϵͳ£¬ËüÄܰѸ÷ÖÖÐÅϢͬµØÀíλÖúÍÓйصÄÊÓͼ½áºÏÆðÀ´£¬²¢°ÑµØÀíѧ¡¢¼¸ºÎѧ¡¢¼ÆËã»ú¿Æѧ¼°¸÷ÖÖÓ¦ÓöÔÏó¡¢Internet¡¢¶àýÌå¼¼Êõ¼°ÐéÄâÏÖʵ¼¼ÊõµÈÈÚΪһÌ壬ÀûÓüÆËã»úͼÐÎÓëÊý¾Ý¿â¼¼ÊõÀ´²É¼¯¡¢´æ´¢¡¢±à¼¡¢ÏÔʾ¡¢×ª»»¡¢·ÖÎöºÍÊä³öµØÀíͼÐμ°ÆäÊôÐÔÊý¾Ý¡£ÕâÑù£¬¾Í¿É¸ù¾ÝÓû§ÐèÒª½«ÕâЩÐÅϢͼÎIJ¢Ã¯µØÊäË͸øÓû§£¬±ãÓÚʹÓᣠȫÇò¶¨Î»ÏµÍ³£¨Global Positioning System,GPS£©ÊÇÉÏÊÀ¼Í70Äê´úÓÉÃÀ¹ú¹ú·À²¿Åú×¼£¬Â½º£¿ÕÈý¾üÁªºÏÑÐÖƵÄÐÂÒ»´ú¿Õ¼äÎÀÐǵ¼º½¶¨Î»ÏµÍ³¡£ÆäÖ÷ҪĿµÄÊÇΪ½¡¢º£¡¢¿ÕÈý´óÁìÓòÌṩʵʱ¡¢È«ÌìºòºÍÈ«ÇòÐԵĵ¼º½·þÎñ¡£È«Çò¶¨Î»ÏµÍ³¹²ÓÉÈý²¿·Ö¹¹³É£ºµØÃæ¿ØÖƲ¿·Ö¡¢¿Õ¼ä²¿·Ö¡¢Óû§×°Öò¿·ÖµÈ¡£GPSµÄÖ÷ÒªÌصãÊÇÈ«Ììºò¡¢È«Çò¸²¸Ç¡¢Èýά¶¨ËÙ¶¨Ê±¸ß¾«¶È¡¢¿ìËÙʡʱ¸ßЧÂʼ°Ó¦Óù㷺¶à¹¦ÄÜ¡£ Ò£¸Ð(Remote Sensing,RS)£¬¹ËÃû˼Ò壬¾ÍÊÇÒ£Ô¶µØ¸ÐÖª¡£ÈËÀàͨ¹ý´óÁ¿µÄʵ¼ù£¬·¢ÏÖµØÇòÉÏÿһ¸öÎïÌ嶼ÔÚ²»Í£µØÎüÊÕ¡¢·¢ÉäºÍ·´ÉäÐÅÏ¢ºÍÄÜÁ¿£¬ÆäÖÐÓÐÒ»ÖÖÈËÀàÒѾÈÏʶµ½µÄÐÎʽ¡ª¡ªµç´Å²¨£¬²¢ÇÒ·¢ÏÖ²»Í¬ÎïÌåµÄµç´Å²¨ÌØÐÔÊDz»Í¬µÄ¡£Ò£¸Ð¾ÍÊǸù¾ÝÕâ¸öÔÀíÀ´Ì½²âµØ±íÎïÌå¶Ôµç´Å²¨µÄ·´ÉäºÍÆä·¢ÉäµÄµç´Å²¨£¬´Ó¶øÌáÈ¡ÕâЩÎïÌåµÄÐÅÏ¢£¬Íê³ÉÔ¶¾àÀëʶ±ðÎïÌå¡£ Ò£¸ÐµÄʵÏÖ»¹ÐèÒªÒ£¸Ðƽ̨£¬ÏñÎÀÐÇ¡¢·É»ú¡¢ÆøÇòµÈ£¬ËüÃǵÄ×÷ÓþÍÊÇÎȶ¨µØÔËÔØ´«¸ÐÆ÷¡£µ±ÔÚµØÃæÊÔÑéʱ£¬»¹»áÓõ½µØÃæÏóÈý½Ç¼ÜÕâÑù¼òµ¥µÄÒ£¸Ðƽ̨¡£Õë¶Ô²»Í¬µÄÓ¦ÓúͲ¨¶Î·¶Î§£¬ÈËÃÇÒѾÑо¿³öºÜ¶à
Re: renaming under CVS
--- Paul Sander <[EMAIL PROTECTED]> wrote: > >> Permissions on a directory basis are tough if > files > >> are linked to > >> multiple directories that have different > >> permissions. > > >I am satisfied with how permissioning is done now > (ie > >per-directory). > > Okay, but this will become a problem depending on > how the containers > are stored. If the files move but the containers > don't, then setting > directory-wide permissions properly will become > difficult. It just occurred to me that if the archive files didn't live within the repo directory (as I had intended), then the permissions on the archive files would be extremely important (and probably impossible to manage). I'll have to rethink this, but as of now, it looks like the archive file will need to live within the repo directory and that a repo-wide archive location mapping will be needed. > Example: > > Begin with contents of directory /a/b, namely, files > c and d. They > have particular permissions. Now move file c do > directory /e/f. > Suppose that directory has a different group > ownership. How are the > permissions of file c affected by the move, and will > the result be > what the user expects? The only archive file permissions that matter are the read and execute permissions. The execute permissions are inherited by the archived file. Those that need to work with the archive file (ie checkin, checout, ...) will need read permissions. Assuming that a file is moved from one directory to another with a different group, and the SGID bit is set on the repo directory, the archive file will be moved adopting the new group. An update to the repo-wide archive location mapping will also be necessary. > Now create directories /a/g and /e/g, where "g" is > really the same > directory, but shared between two projects. Move > file d into directory > g. It should appear in both projects, but what are > its permissions? Sharing of directories will no longer be supported since "complex" module definitions will no longer be supported. > My concern here is that what we today think of as > modules would never > disappear without substantial effort. Consequently, > "cvs rm" shouldn't > be permitted in the top level. I still don't understand. Can you give an example? > >> Also, I was considering using a special container > >> name of "0" to locate > >> the top-level definitions. > > >"0" (well, more likely 64 0's) sounds good to me. > >There also needs to be a way to add/remove from > this > >top-level list. What do you think of switches to > >"add" and "rm"? > > I figured it would be treated like any other > directory, with the > exception that "rm" would be disallowed. I have no > problem with > people adding new projects, but there should be a > trigger on "add" > to enforce local policies. I think the trigger architecture needs an overhaul and since the existing one can be used to enforce "add" policies, I'd rather concentrate on the meaty issues at hand. > >Also, I'm not a fan of completely wiping out > archive > >files, but I can see a need for it. This also > needs > >more consideration. > > I'm also happy to leave them there, though there is > an argument to > moving them to a lost+found area if no directory > version references > them. I'm not sure if this is completely true. I think the Attic, especially when coupled with the directory-specific mapping, can serve this purpose. Of course, I could be wrong, but I think any issues that do arise won't be too severe. > >I do know that CC uses "ln" to resurrect files. I > >never really liked this (since it's not so > intuitive), > >but this need still exists so I'll try to find some > >other way to address it. > > Regardless of whether or not the capability is > available on the > command line, the mechanism is needed for the > directory merge > algorithm. Consider also that "cvs ln" need not > necessarily > equate to a Unix "ln"; it's merely a means to attach > a name to > a container in a new location of a user's sandbox. > At this early > stage, I believe that the implementation will be > closer to a text > file edit (that represents the parent directory) > followed by a > "cvs update" on the newly attached file. But that's > just a thought, > not a design. I was thinking that the users' sandboxes would have the filename mapping within its CVS/Entries files. For example, let's say file asdf.cc is mapped to 01ef,v (I'll use four nibble archive names to save on bandwidth). CVS/Entries will store this information. The client will look up the archive name from CVS/Entries and will use only that name when communicating with the server. The server will then lookup the location of that archive within the repo using the repo-wide archive location mapping. Everything else should work as it does now, more or less. > I believe than any implementation of "cvs mv" would > require an > overhaul of CVS' locking protocol if it were to > perform well. > Once y
Re: CVS and Jar files: Should you import Jar into the Repository? Why or why not
--- Christian Andersson <[EMAIL PROTECTED]> wrote: > (we have started to intruduce our own version > functionallity in the code so > that we can ask what version of the class we are > running, and thisin all the > classes we create ourselves, if we are extending a > class, we first make our > own abstract class of this class that implements the > Version interface, all > classes then extends this new class and thus have to > implement the version > interface) You might want to take a look at AspectJ for something like this. Noel __ Do You Yahoo!? Try FREE Yahoo! Mail - the world's greatest free email! http://mail.yahoo.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
CVS, SSH, (Light) Security
[sorry if you see this twice, my first attempt seemed to go into nowhere at a time when my ISP ws having problems] I have a repository which is, for firewall and other practical reasons) accessible only by ssh (ie CVS_RSH=ssh and :ext: repository name). I would like to give some people read only access. Preferrably only to some modules. CVS provides no support, as it does for pserver. I can't, so far as I can see, use file permissions, users need write acess to the repository to make lockfiles etc all over the place. The best temporary solution I have been able to come up with is a combination of Give them ssh access with a restricted shell that only allows cvs seerver to be run. Create a commit test which fails for that user (Actually I do it based on groups). This is ugly and only partially works. Eg they can play with tags and probably other potentially damaging things. For the current user this is not a problem, I am really only trying to prevent accidental errors, but in future I think I am loikely to need more. Does anyone have a better solution? -- Mail me as [EMAIL PROTECTED]_O_ |< ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS and Jar files: Should you import Jar into the Repository? Why or why not
--- "Greg A. Woods" <[EMAIL PROTECTED]> wrote: > It also depends a _GREAT_ deal on what the file > contains. Jar files do > not contain easily diff-able and patch-able text and > therefore are not > appropriate for storage in CVS. Is this really true? Has anyone tried javap'ing the contents of a jar file, then diff'ing and patch'ing that, then recreating the jar file (I'm not sure how this final step would be done if it's even possible)? Noel __ Do You Yahoo!? Try FREE Yahoo! Mail - the world's greatest free email! http://mail.yahoo.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS and Jar files: Should you import Jar into the Repository? Why or why not
--- Richard Caley <[EMAIL PROTECTED]> wrote: > Unless you can come up with a bigger problem with > using CVS, you are > not going to convince anyone. I beg to differ. I think acadamecians would easily give in to these arguments :-) Noel __ Do You Yahoo!? Try FREE Yahoo! Mail - the world's greatest free email! http://mail.yahoo.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS and Jar files: Should you import Jar into the Repository? Why or why not
--- "Greg A. Woods" <[EMAIL PROTECTED]> wrote: > Versioning _is_ diffs! There's no point to keeping > every revision of > every file unless you can calculate a _meaningful_ > delta between them! > Not even if your storage scheme is to keep each > revision of the whole > file as a unique object. Versioning is used to identify components of a product and to control the changes that go into that product. Diffs are not necessary to do this. I've even worked in an environment that didn't use a tool (purely procedures and processes) to achieve this. Noel __ Do You Yahoo!? Try FREE Yahoo! Mail - the world's greatest free email! http://mail.yahoo.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS and Jar files: Should you import Jar into the Repository? Why or why not
--- Richard Caley <[EMAIL PROTECTED]> wrote: > There is a bigger issue for non-sane formats. > Notably Word documents > which can't be diffed but logically should be. The > solution here is to > shoot anyone who brings one near your project:-). Technically, they can be diff'ed, but you'd probably have to pay to have the privelege of doing so :-) Noel __ Do You Yahoo!? Try FREE Yahoo! Mail - the world's greatest free email! http://mail.yahoo.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
failed to move file out of the attic: Permission denied
I got the error: failed to move `D:/CVSReps/ ... /xxx,v' out of the attic: Permission denied when I try to "resurrect" a file previously deleted. I've read that it has been a big bug of cvs but has been already solved... The user has full permission on all the directories on the cvs-server... The server is the last version running on Windows 2000 (CVSNT 1.11.1.3 rc2 (Build 55)), but i got this problem with version 1.11.1.2(build 41) too Can someone help me? Regards Valerio Bottari PS:Here is the socket comunication i make: 07/mar/2002 11:30:31.931 [main] - C: BEGIN AUTH REQUEST 07/mar/2002 11:30:31.931 [main] - C: /uno 07/mar/2002 11:30:31.941 [main] - C: admin 07/mar/2002 11:30:31.941 [main] - C: Aye%?= 07/mar/2002 11:30:31.941 [main] - C: END AUTH REQUEST 07/mar/2002 11:30:34.425 [main] - S: I LOVE YOU 07/mar/2002 11:30:34.435 [main] - C: Root /uno 07/mar/2002 11:30:34.435 [main] - C: Valid-responses E M ok error Valid-requests Created Merged Updated Update-existing Removed Remove-entry New-entry Checked-in Checksum Copy-file Notified Clear-sticky Set-sticky Clear-static-directory Set-static-directory 07/mar/2002 11:30:34.445 [main] - C: UseUnchanged 07/mar/2002 11:30:34.445 [main] - C: Argument -m 07/mar/2002 11:30:34.445 [main] - C: Argument pvs commit 07/mar/2002 11:30:34.445 [main] - C: Directory . 07/mar/2002 11:30:34.455 [main] - C: /uno/mod1/Sanremo/Giovani 07/mar/2002 11:30:34.455 [main] - C: Entry /alexia.jpg/0/// 07/mar/2002 11:30:34.455 [main] - C: Modified alexia.jpg 07/mar/2002 11:30:34.465 [main] - C: u=rw,g=r,o=r 07/mar/2002 11:30:34.465 [main] - C: 6436 07/mar/2002 11:30:34.465 [main] - C: Sending data... 6436 bytes 07/mar/2002 11:30:34.465 [main] - C: 6436 bytes successfully sent 07/mar/2002 11:30:34.475 [main] - C: Argument alexia.jpg 07/mar/2002 11:30:34.475 [main] - C: ci 07/mar/2002 11:30:34.915 [main] - S: E cvs server: failed to move `D:/CVSReps/uno/mod1/Sanremo/Giovani/Attic/alexia.jpg,v' out of the attic: Permission denied 07/mar/2002 11:30:35.016 [main] - S: error ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS and Jar files: Should you import Jar into the Repository? Why or why not
--- Lee Sau Dan <[EMAIL PROTECTED]> wrote: > Christian> Well since I come from a windows > enviroment, cvs is > Christian> mainly used as a version control > system, diff/merge is > Christian> not used that much by us (yet) and we > use cvs because > Christian> was the most cost-effective we could > find.. > > Most CVS users will disagree with you. For me, > the main reason for > using CVS/RCS is to be able to diff/merge between > versions. If these > operations are not needed, I'd simply store > different versions under > different file/directory names, so that I can > access any version much > more directly (no need to checkout/update first). I agree with Christian. If all you need is diff/merge capabilities, you already have diff, diff3, and patch. > Windows/DOS gives you a very very very confined > view of the giant > world. That's why I use Cygwin when on Windoze. Noel __ Do You Yahoo!? Try FREE Yahoo! Mail - the world's greatest free email! http://mail.yahoo.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS and Jar files: Should you import Jar into the Repository? Why or why not
> "Noel" == Noel Yap <[EMAIL PROTECTED]> writes:
>> Windows/DOS gives you a very very very confined view of the
>> giant world.
Noel> That's why I use Cygwin when on Windoze.
Yeah! That provides refuge! But it's never the real things. It's
just a pretty giftwrap around a rotten egg: still broken down inside.
For the real thing, I'll get Linux.
--
Sau Dan LEE §õ¦u´°(Big5)~{@nJX6X~}(HZ)
E-mail: [EMAIL PROTECTED]
Home page: http://www.informatik.uni-freiburg.de/~danlee
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS and Jar files: Should you import Jar into the Repository? Why or why not
--- "Greg A. Woods" <[EMAIL PROTECTED]> wrote: > It matters not what the Paul > Sander's of the world > might claim is possible -- I speak of what _is_, > right now, today. What _is_ right now, today, is that many developers use CVS to manage non-diff3-able files. The proof is in the pudding -- CVS is _usable_ for such files, but it's not ideal. Have you ever used a ruler as a straight-edge? > You could do all of what any versioning tool does > with pencil and paper > alone, but these tools make such tasks much less > painful. They do much > of the accounting for you and prescribe a process > that makes remembering > all the necessary steps much easier too. And CVS accomplishes all this with non-diff3-able files (much better than paper and pencil, anyway). > And thus CVS was born with it's inherent design > feature that effectively > requires you to allow for the possibility of > concurrent edits. And so you can take care of this issue (ie possibility of concurrent on non-diff3-able files) with processes. > It is far easier than you might think. There's an > entire world of > alternatives out there. I think it's evident that none of them are satisfactory to at least some. Noel __ Do You Yahoo!? Try FREE Yahoo! Mail - the world's greatest free email! http://mail.yahoo.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: CVS and Jar files: Should you import Jar into the Repository? Why or why not
--- "Greg A. Woods" <[EMAIL PROTECTED]> wrote: > Sure, it's possible, but it does not work well and > it does not give any > meaning to the results that cannot better be > obtained in any number of > other possible ways. But it works well enough. If it didn't, those using it would find a better alternative. > On the contrary! _ANYTHING_, in general, is much > better! But it's not worth it. For example (assuming income is the metric), I might decide to change jobs and earn %.0001 more than I am now, but it's not worth it. Noel __ Do You Yahoo!? Try FREE Yahoo! Mail - the world's greatest free email! http://mail.yahoo.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS and Jar files: Should you import Jar into the Repository? Why or why not
--- "Greg A. Woods" <[EMAIL PROTECTED]> wrote: > C code isn't in a typically linear text format > either, but the way most > people lay it out in a typical linear text file > lends itself very well > to manipulation with diff/diff3/patch -- so well > that research and tons > of practical experience has shown time and time > again that even with > concurrent edits (i.e. merges on almost half of all > edits) there are > very few worrisome conflicts. > > Indeed even English text isn't easily diffable > unless you lay it out in > a way that suits diff/diff3/patch. One such way > that's particularly > effective is the way traditionally suggested for > troff documents. Lines > must end at the end of every sentence. (Obviously > with troff you don't > care if paragraphs are nicely wrapped and filled! > ;-) You're absolutely right. So, in essence, although it's theoretically not correct to use diff3 on C files, it works in practice, so CVS does it. Similarly, CVS works in practice with non-diff3-able files so people use it. Noel __ Do You Yahoo!? Try FREE Yahoo! Mail - the world's greatest free email! http://mail.yahoo.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Strange CVS error- Pls help
Rob Helmer writes: > > Yes, you need an RSH client on your local machine, or > the CVS client will not be able to connect to the CVS server. Many CVS clients have a built-in rsh client -- that's the :server: access method (as opposed to :ext: for an external rsh client). -Larry Jones Isn't it sad how some people's grip on their lives is so precarious that they'll embrace any preposterous delusion rather than face an occasional bleak truth? -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: CVS and Jar files: Should you import Jar into the Repository? Why or why not
> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, March 06, 2002 3:11 PM > To: [EMAIL PROTECTED] > Subject: RE: CVS and Jar files: Should you import Jar into the > Repository? Why or why not > > > [ On Wednesday, March 6, 2002 at 14:21:56 (-0600), Thornley, > David wrote: ] > > Subject: RE: CVS and Jar files: Should you import Jar into > the Repository?Why or why not > > > > I still fail to understand the problem. > > What's to UNDERSTAND? CVS manages source files which are diffable and > patchable. Other things manage other kinds of files. You > tie all these > things together in whatever overall build and release management > processes and procedures you will need for all but he most mundane of > projects. There are apparently even already tools that make > short work > of tying these things together for Java JAR files! > What's to understand? Simply, why I should not control some binary files with CVS. So far, for all your rhetoric, you have failed to actually tell me any specifics about a problem. Further, CVS manages source files that are not diffable and patchable. I've done it. Other things also manage these sorts of files, but CVS will do it. CVS doesn't do as well with these files as with (say) C source files, but this isn't a cause for alarm. > > > Simple directory naming schemes are almost infinitely better! > > > > In what way is a directory naming scheme, or named > tarballs, infinitely > > better? > > It has all the features and capabilities necessary to fulfill your > requirements for keeping many revisions of binary files, and > it has none > of the drawbacks of CVS. > I can keep many revisions of binary files in CVS. Granted, a large file with lots of changes will have a very large ,v file eventually, and this may be an issue, but it isn't necessarily the case, and indeed I haven't run into such a case. The files that cause the most performance issues in our repository are large text files with lots of revisions. Now, it may be that CVS would have problems with large and frequently changed files, but not all binary files are like that. If I kept *.o files in the repository, I'd expect problems. As it is, the problems caused by the binary files I've got (both at work and at home) are less troublesome than the problems caused by the sorts of files CVS is supposed to handle. > > In order for it to be infinitely better, I'd need to be causing > > infinitely hard problems by keeping binaries under CVS control. > > Unless you can securely isolate all your non-diffable and > non-patchable > files in modules separate from your source files, and unless you can > ensure all your CVS tools (client, server, etc.) properly handle all > aspects of binary files, and unless you can securely > implement policies > stating how those modules containing binary files are to be used and > manipulated, you cannot safely use CVS in general to track > revisions of > binary files. > Why not? I call them "-kb" on creation. That seems to have protected them just fine. I have had no, repeat no, cases of file corruption. > However even a simple naming scheme "just works". That seems to be > infinitely better to me! > Although you have notably failed to provide what I asked for, namely something in the way of use cases to show problems in using CVS to store binaries, I'm going to discuss possible ways in which such schemes can fail. Suppose we have one master directory, with subdirectories specifying branches and subdirectories below these specifying dates. We will assume that these directories are executable and readable for all the developers, and writeable for an administrator. What sorts of things can go wrong? 1. Somebody can make a change and fail to notify the administrator, or the administrator can be out or otherwise occupied and fail to record a change. This can mean a missed change, or a misdated one. (Note that this can be partly alleviated by allowing the developers to add files to the repository. I'd be scared that they'd misname or overwrite something. One thing CVS does is ensure that, unless somebody has direct repository access, they are limited in what they can do, and cannot, unless they use "cvs admin" (which you can restrict with OS groups), lose any versions. They can lose tags, which is a problem, but not versions.) 2. The administrator can misname a directory accidentally, or fail to create a new directory because the changes seem so small. In this model, there will be a very strong tendency to keep only versions that seem significant, and this may cause problems later. 3. A directory could be removed somehow and not be noticed for a long time. The only safe way to deal with this is to have independent backups going back to day 1. 4. Looking through the dated directories and finding the one with the latest date before the intended date is tedious and error-prone, and any failure
Re: CVS and Jar files: Should you import Jar into the Repository? Why or why not
--- Lee Sau Dan <[EMAIL PROTECTED]> wrote: > Noel> I'm assuming you mean a straight-edge, not > a ruler? > > Isn't a ruler for drawing rules, i.e. straing lines? Funny, the dictionary definition for "ruler" agrees with you (although it did add the measuring part as well), but the thesaurus entry for "rule" mentions only measuring, not drawing. I think the dictionary definition has given in to instrument usage pressure instead of keeping the intended meaning. In any case, this is still a good analogy since, according to some, if you're not using the measuring capabilities, you should be using a straght-edge. > Noel> Actually, this brings up an even better > analogy: A ruler is > Noel> meant to measure things, not as a > straight-edge. > > I've never seen any "ruler" that does not provide a > straight edge. When used often enough as a straight-edge, some rulers (eg wooden ones) lose their straightness. These aren't meant to be used as straight-edges. > Noel> There are text formats that aren't easily > mergable (eg XML) > > It depends on what tools you use to edit the XML > files. IOW, it depends on the layout of the text file. > Noel> and binary formats that can be mergable > (eg Word). > > B'cos the data encoded inside is just text in > nature. I think you're missing the point here. Let me explain in more detail. CVS cannot diff/merge Word documents even though there exists a well-defined diff/merge algorithm for them. CVS may or may not be able to diff/merge (in any meaningful way) text files depending on how they're laid out. IOW, the text or binary attribute of a file has nothing to do with its diff or merge attribute. The two attributes should not be confused. > Noel> Or, more likely, well enough for your > needs. Since XML > Noel> isn't the typical linear text format (ie > it's hierarchical), > Noel> diff3 isn't the ideal three-way diff tool > to use. > > Why not? Pascal programs, for instance, are highly > hierarchical. But > they should (I've never tried) work well with CVS. You're right, my example isn't ideal. But if you think about it, a "correct" diff/merge for XML, Pascal, etc would be a tree diff/merge, not a linear one. In the end, diff3 works because humans break the files into human-readable lines, not because of anything inherent in the file formats. Noel __ Do You Yahoo!? Try FREE Yahoo! Mail - the world's greatest free email! http://mail.yahoo.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS, SSH, (Light) Security
Read up on the LockDir configuration setting. Noel --- Richard Caley <[EMAIL PROTECTED]> wrote: > > [sorry if you see this twice, my first attempt > seemed to go into > nowhere at a time when my ISP ws having problems] > > I have a repository which is, for firewall and other > practical > reasons) accessible only by ssh (ie CVS_RSH=ssh and > :ext: repository > name). > > I would like to give some people read only access. > Preferrably only to > some modules. > > CVS provides no support, as it does for pserver. > > I can't, so far as I can see, use file permissions, > users need write > acess to the repository to make lockfiles etc all > over the place. > > The best temporary solution I have been able to come > up with is a > combination of > > Give them ssh access with a restricted shell > that only allows > cvs seerver to be run. > > Create a commit test which fails for that > user (Actually I do > it based on groups). > > This is ugly and only partially works. Eg they can > play with tags and > probably other potentially damaging things. For the > current user this > is not a problem, I am really only trying to prevent > accidental > errors, but in future I think I am loikely to need > more. > > Does anyone have a better solution? > > -- > Mail me as [EMAIL PROTECTED]_O_ > |< > > ___ > Info-cvs mailing list > [EMAIL PROTECTED] > http://mail.gnu.org/mailman/listinfo/info-cvs __ Do You Yahoo!? Try FREE Yahoo! Mail - the world's greatest free email! http://mail.yahoo.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Custom error message to client
Norberto Meijome writes: > > I've tried a simple > echo 'msg' > exit 1 > > and > > echo 'msg' >/dev/stderr > exit 1 > > but I just get in the client: > > cvs [login aborted]: recv() from server cvs.au.office.aol.com: > Connection reset by peer > > *CVS exited normally with code 1* > > Does anybody know where can I find a pointer to the proper way of doing > this? The client/server protocol is documented in doc/cvsclient.texi. Basically, you should do something like: #! /bin/sh echo 'E This is a message to be displayed' echo 'I HATE YOU' Make sure you have the #! line -- most systems won't exec scripts without one. -Larry Jones What this games needs are negotiated settlements. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Cannot use taginfo file
Zinger writes: > > I tried to put into taginfo this line : (PS : This command is also stored > into loginfo and comit. and that's work for these files) > ALL (echo "To: [EMAIL PROTECTED]"; echo "Subject: tag created"; echo; cat) | > /usr/lib/sendmail -t > > When i try to create a tag, i receive this message : > cvs server: cannot exec (echo: No such file or directory > cvs server: Pre-tag check failed > cvs [server aborted]: correct the above errors first! You need to put that into a script and just put the name/path of the script in the taginfo file. Most of the administrative files are processed with a very simple parser that doesn't even understand quoted strings, let alone built-in shell operators like parentheses and pipes. -Larry Jones I suppose if I had two X chromosomes, I'd feel hostile too. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Get diff between two releases
Eric Gambardella writes: > > I would like to know if it is possible to get only > the changed files between two releases (two different tags) > in order to give a patch as small as possible. cvs patch (aka rdiff) -Larry Jones How am I supposed to learn surgery if I can't dissect anything? -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS, SSH, (Light) Security
Richard Caley writes: > > I can't, so far as I can see, use file permissions, users need write > acess to the repository to make lockfiles etc all over the place. Use LockDir= in your CVSROOT/config file to put the lock files somewhere other than in the repository. Then you can use file permissions to do what you want. -Larry Jones I won't eat any cereal that doesn't turn the milk purple. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS, SSH, (Light) Security
> "Richard" == Richard Caley <[EMAIL PROTECTED]> writes: Richard> Richard> I would like to give some people read only access. Preferrably only to Richard> some modules. Richard> Richard> CVS provides no support, as it does for pserver. Richard> Richard> I can't, so far as I can see, use file permissions, users need write Richard> acess to the repository to make lockfiles etc all over the place. That's not the same as giving them write permission on the individual files. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS, SSH, (Light) Security
Mark A. Flacy writes: > > That's not the same as giving them write permission on the individual files. Write permission on the individual repository files is irrelevant (normally, *no one* has write permission). Only directory permissions matter to CVS. -Larry Jones You can never really enjoy Sundays because in the back of your mind you know you have to go to school the next day. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
commit error: you are unknown to this system
Hi all, We've started using a CVS pserver on monday in our organization and we are facing some problems. We can do checkouts and import but when the time to commit comes problems arise... In the beginning I connected as root and got the "you cannot commit as root" error... good... I found out CVS doesn't allow root to commit and this feature is hard coded... Since we do not intend to rebuild cvs we went on setting up access for other users. we have set up the passwd file under cvsroot using aliases. eg mirco maps to mirco.bova which is a system user. as Mirco I can do checkouts mark file for editing and so on but when I try to commit I always get the following error: cvs commit -m test VAR.H (in directory C:\ciccio\prova\H\) cvs [server aborted]: you are unknown to this system Can anyone help? I tried looking at the list archive but up now I found nothing similiar. Thanks, Mirco ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Request for Help: Bulk adding new files to a branch
On Wed, Mar 06, 2002 at 04:54:53PM -0800, Terry Spafford wrote: > We have decided that we don't care about the history of the files from > the old CM system, BUT we want the current versions of all those > branches from the old CM system checked into CVS as branches off of the > current project. (Since they were all derived from this trunk at some > point and we want to easily be able to compare them together when needed). > [...] > Note that we are never expecting to have to merge any of these customer > branches back onto the Trunk; we just want to be able to compare the > code CustomerA has with what CustomerB has and make changes to their > code to fix bugs and/or add improvements as needed/requested. CVS branches are better at handling temporary branches in development than they are at handling permanent -- and thus permanently diverging -- variants. If nothing else, in sheer mechanical terms -- the more revisions you commit to a branch, the slower it gets; the trunk doesn't slow down that way. (Recall that the trunk revisions are stored as reverse deltas from HEAD, whereas branch revisions are stored as *forward* deltas from the branch point.) Since you never expect to merge, one could think of your code base as consisting of not one application, but a collection of (presumably) very similar ones. Given that, I don't believe they all belong together in CVS. Better to keep customer's version of the code in its own separate CVS module; then, if appropriate, use branches within each of those modules for their more usual purposes -- ones that *do* ultimately end up merging back into the trunk, like bugfix branches, experimental lines of development, and such. I know that this suggestion goes very much against the grain. It does for me too; I've thought carefully before recommending it. But I think that in your situation, it might make sense. Ideally, of course, you'd refactor the code into common and per-customer modules, so that the former need be maintained only once. That would give you a much saner code base, which could reasonably be thought of as one application with customizations. But practically speaking, if that's just not going to happen, thinking of it instead as N related applications might be more useful, as hard a pill as that might be to swallow. (And if you're really lucky, perhaps an argument along those lines might persuade the powers that be to fund a refactoring effort :-) -- | | /\ |-_|/ > Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / "Outlook not so good." That magic 8-ball knows everything! I'll ask about Exchange Server next. - Anonymous ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS, SSH, (Light) Security
In article <[EMAIL PROTECTED]>, Mark A Flacy (maf) writes: Richard> I can't, so far as I can see, use file permissions, users need write Richard> acess to the repository to make lockfiles etc all over the place. maf> That's not the same as giving them write permission on the individual files. But if I start some policy of controling individual file permissions it means some poor sod has to make sure every file checked in has the right permissions, or a regular process does. Yeuch. And if they can write the directory to make a lock file/directory they can presumably check in new files and who knows what else might sneak through. If CVS created it's lock files outside the repositary itself, then simple access controls on the whole repository would work and that would be much cleaner. Then I could put each module directory in the repository into it's own group and control access that way. -- Mail me as [EMAIL PROTECTED]_O_ |< ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS, SSH, (Light) Security
In article <[EMAIL PROTECTED]>, Noel Yap (ny) writes: ny> Read up on the LockDir configuration setting. Yep, that seems like the right direction. Thanks. -- Mail me as [EMAIL PROTECTED]_O_ |< ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: commit error: you are unknown to this system
Mirco Bova writes: > > we have set up the passwd file under cvsroot using aliases. eg mirco maps to > mirco.bova which is a system user. > > as Mirco I can do checkouts mark file for editing and so on but when I try > to commit I always get the following error: > > cvs commit -m test VAR.H (in directory C:\ciccio\prova\H\) > cvs [server aborted]: you are unknown to this system That means that the CVS server is running as root (which it shouldn't be) and your CVS username isn't a valid system username. You say mirco maps to mirco.bova in CVSROOT/passwd, is mirco.bova just an alias for root (i.e., uid 0)? -Larry Jones The problem with the future is that it keeps turning into the present. -- Hobbes ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: commit error: you are unknown to this system
Mirco Bova writes [quoting me]: > > >That means that the CVS server is running as root > >(which it shouldn't be) > > Why? I mean we found some exaples in cederqvist where cvs pserver was > running as root. > > 2401 stream tcp nowait root /usr/local/bin/cvs > cvs --allow-root=/usr/cvsroot pserver > > pherhaps we wisunderstood something? I should have been more clear. The server starts out running as root, but it only runs as root long enough to validate the client's specified username and password; as soon as that's done, it changes user to run as the specified user. You get the "unknown to this system" message because you're still running as uid 0 after that switch. > >and your CVS username isn't a valid system username. > >You say mirco maps to mirco.bova in CVSROOT/passwd, > >is mirco.bova just an alias for root (i.e., uid 0)? > > no mirco.bova is a normal user. We also tried mapping mirco to root > but it doesn't work... Are you sure you're running as mirco? CVS saves the connection information (including the username) for a working directory (in CVS/Root) when you first check it out and then uses that saved information rather than $CVSROOT for all subsequent operations. You might want to checkout a new working directory and see if that solves the problem. -Larry Jones Who, ME? Who?! Me?? WHO... Me?! Who, me??? -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Abandoned CVS server processes
Dan Peterson writes: > > I've seen ESTABLISHED and IDLE. That's interesting, there is no official TCP state called IDLE. I wonder what it means? Certainly both states imply that the connection is alive and well as far as the system can determine. > 1. Only a single process exists and it's parent is "inet". Perhaps this > is normal, if the client doesn't disconnect after each request? WinCVS is > just a front end for a DOS command interface isn't it? So wouldn't that > mean the connection should only remain open for a long checkout or commit > (or update or tag, etc)? Correct. Having a single process is typical of a server that isn't executing a CVS subcommand at the moment, but is rather processing the client/server protocol. > These processes appear to be in some kind of wait state and don't seem to > be using any CPU time. Using truss I've found them in read(), poll() and > write() calls. They have been hanging around for several hours. > > This appears like it might be the case you described where the client went > away and TCP is waiting around? Most likely. It sounds like the server is waiting for a command from the client. > 2. Two processes; the first has a parent of "inet" and it's child seems > to be spinning and using lots of CPU (after about 34 hours one process has > used about 24 hours of CPU). The sockets associated with the first > process are in an IDLE state. That would indicate a bug in CVS. > I attached to each of the processes in this state with gdb and determined > they were spinning in a tight loop inside rcs.c:translate_symtag(). This is a bug that I just recently fixed -- translate_symtag would go into an infinite loop if the tag was "". -Larry Jones My life needs a rewind/erase button. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS, SSH, (Light) Security
[ On Thursday, March 7, 2002 at 17:52:01 (GMT), Richard Caley wrote: ] > Subject: Re: CVS, SSH, (Light) Security > > But if I start some policy of controling individual file permissions > it means some poor sod has to make sure every file checked in has the > right permissions, or a regular process does. Yeuch. The point is that you cannot easily implement any policy that control access to individual files. CVS only works normally with per-directory access controls. You can muck about with scripts called by commitinfo, but that's not really guaranteed to be secure -- it would just be "advisory" security. > And if they can write the directory to make a lock file/directory they > can presumably check in new files and who knows what else might sneak > through. Yes, that's exactly right, which is why you need to move the lock directories somewhere else. > If CVS created it's lock files outside the repositary itself, then > simple access controls on the whole repository would work and that > would be much cleaner. Then I could put each module directory in the > repository into it's own group and control access that way. Indeed. That's why CVS has this feature that everyone's been trying to tell you about. Here's the blurb from the manual (in the "config" node): LockDir=DIRECTORY' Put CVS lock files in DIRECTORY rather than directly in the repository. This is useful if you want to let users read from the repository while giving them write access only to DIRECTORY, not to the repository. It can also be used to put the locks on a very fast in-memory file system to speed up locking and unlocking the repository. You need to create DIRECTORY, but CVS will create subdirectories of DIRECTORY as it needs them. For information on CVS locks, see *Note Concurrency::. Before enabling the LockDir option, make sure that you have tracked down and removed any copies of CVS 1.9 or older. Such versions neither support LockDir, nor will give an error indicating that they don't support it. The result, if this is allowed to happen, is that some CVS users will put the locks one place, and others will put them another place, and therefore the repository could become corrupted. CVS 1.10 does not support LockDir but it will print a warning if run on a repository with LockDir enabled. The lock heriarchy could even be world writable, and certainly it needs to be writable by the unprivileged user-ID used to grant anonymous read-only access. You'll have to keep your eyes on it anyway lest a vulnerability in CVS somehow allow anonymous users to write arbitrary data to it. -- Greg A. Woods +1 416 218-0098; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Planix, Inc. <[EMAIL PROTECTED]>; VE3TCP; Secrets of the Weird <[EMAIL PROTECTED]> ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS, SSH, (Light) Security
--- "Greg A. Woods" <[EMAIL PROTECTED]> wrote: > The point is that you cannot easily implement any > policy that control > access to individual files. CVS only works normally > with per-directory > access controls. You can muck about with scripts > called by commitinfo, > but that's not really guaranteed to be secure -- it > would just be > "advisory" security. It's not necessarily "advisory" security. For example, in order to effectively use file system ACLs, one would need a loginfo script that would set the appropriate ACLs. If the script didn't exist, some wouldn't get the permissions they needed. IOW, the script grants permissions, rather than denies them. Noel __ Do You Yahoo!? Try FREE Yahoo! Mail - the world's greatest free email! http://mail.yahoo.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Abandoned CVS server processes
On Thu, 7 Mar 2002, Larry Jones wrote: > Dan Peterson writes: > > > > I've seen ESTABLISHED and IDLE. > > That's interesting, there is no official TCP state called IDLE. I > wonder what it means? Certainly both states imply that the connection > is alive and well as far as the system can determine. I should clarify... the "TCP state" information was found by doing an lsof on the process with a PPID of "inet". On the 3 open file descriptors (stdin, stdout and stderr) which are tied to the socket, the "NAME" column shows: server:port->client:port (IDLE) I assumed the value in '()'s was the TCP state. Unfortunately I don't have any processes in this "spinning" state at the moment, so I can't tell what netstat shows. PS. I just looked at the man page for lsof and it does say the value in parentheses is the "TCP or TPI state name". ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
XML diff and merge
Noel Yap <[EMAIL PROTECTED]> wrote, among lots more in a posting titled "Re: CVS and Jar files: Should you import Jar into the Repository? Why or why not" ... quote ---> But if you think about it, a "correct" diff/merge for XML, Pascal, etc would be a tree diff/merge, not a linear one. <--- quote IBM agrees; see ... http://www.alphaworks.ibm.com/tech/xmltreediff ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
How To Find What Has NOT Been Tagged
I've applied a tag to a given sandbox. It appears that that sandbox may not have been complete. How do I check which files do NOT have a particular tag associated with one of its revisions? -- Jake Colman Principia Partners LLC Phone: (201) 946-0300 Harborside Financial Center Fax: (201) 946-0320 902 Plaza Two E-mail: [EMAIL PROTECTED] Jersey City, NJ 07311 www.principiapartners.com ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
updating CVS server
is replacing the cvs executable we have (1.11) with 1.11.1p1 safe? We are doing this on the server. The clients are all 1.11.1p1. building from source did not work, because config script thought we had kerberos although we had sun. We found the new executable and replaced with the old one... Any problems? ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: sccs2rcs to perl
Michael Sterrett -Mr. Bones.- writes: > > It would be nice to receive some comment from the CVS development team. > This is the third time I've sent this out the the mailing lists with not > a peep from anyone about it. Very disappointing. contrib/README: "Unsupported" also means that no one has volunteered to accept and check in changes to this directory. So submissions for new scripts to add here are unlikely to be accepted. Suggested changes to the existing scripts here conceivably might, but that isn't clear either, unless of course they come from the original author of the script. If you have some software that works with CVS that you wish to offer it is suggested that you make it available by FTP or HTTP and then announce it on the info-cvs mailing list. -Larry Jones You can never really enjoy Sundays because in the back of your mind you know you have to go to school the next day. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: sccs2rcs to perl
On Thu, 7 Mar 2002, Larry Jones wrote: > contrib/README: > > "Unsupported" also means that no one has volunteered to accept and check > in changes to this directory. So submissions for new scripts to add > here are unlikely to be accepted. Suggested changes to the existing > scripts here conceivably might, but that isn't clear either, unless of > course they come from the original author of the script. > > If you have some software that works with CVS that you wish to offer it > is suggested that you make it available by FTP or HTTP and then announce > it on the info-cvs mailing list. > > -Larry Jones Larry -- Thanks for the response. I guess I'm just a little naive when it comes to the development process of CVS. I assumed that any sort of improvement to the distribution would be welcome. In my involvement in open source projects in the past, the maintainers of the projects have been very receptive and pleased to receive code, which they didn't have to write. I see a problem with the CVS code as distributed. That is, it has a single csh script which is both slow and makes the CVS code-base depend on an additional unix "utility" when it doesn't have to. I believe I addressed both of these problems with my re-write of the script in perl. I've announced it on the info-cvs list (a couple of times now) and I'd like to make it available via FTP in the CVS distribution if I could just get some cooperation from you, Derek or one of the other silent CVS developers. Thanks, Michael Sterrett -Mr. Bones.- [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: updating CVS server
Arcin Bozkurt - Archie writes: > > building from source did not work, because config script thought we had > kerberos although we had sun. We found the new executable and replaced > with the old one... > > Any problems? Shouldn't be, but it's always a good ideas to check NEWS for important changes:
Re: updating CVS server
On Thu, Mar 07, 2002 at 05:31:39PM -0500, Arcin Bozkurt - Archie wrote: > is replacing the cvs executable we have (1.11) with 1.11.1p1 safe? We > are doing this on the server. The clients are all 1.11.1p1. This should be fine, as far as I know. > building from source did not work, because config script thought we had > kerberos although we had sun. We found the new executable and replaced > with the old one... Solaris 8, right? Known bug, fixed in development I believe. Try adding these options to the "configure" command line: --without-krb4 --without-gssapi -- | | /\ |-_|/ > Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / "Outlook not so good." That magic 8-ball knows everything! I'll ask about Exchange Server next. - Anonymous ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: How To Find What Has NOT Been Tagged
Jake Colman writes: > > I've applied a tag to a given sandbox. It appears that that sandbox may not > have been complete. How do I check which files do NOT have a particular tag > associated with one of its revisions? Simplest way I can think of is to update the sandbox to a revision that is complete, then do "cvs up -r tag" and see which files are "no longer in the repository". -Larry Jones I don't think that question was very hypothetical at all. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Strange errors when checking out to NFS-mounted home directories
Hello, At work, we are getting strange errors when checking out to our home directories which are mounted via NFS from a Network Appliance. The errors seem to occur when checking out specific tags, but mostly when running an update with both the "-P" and "-d" flags, such as "cvs -q up -P -d". Here is a sample of the error messages: Using "cvs co -r tag austin": cvs checkout: cannot remove austin/old_public_html/customers: Unknown error 523 cvs checkout: cannot remove austin/old_public_html/active_markets: Unknown error 523 cvs checkout: cannot remove austin/old_public_html/Templates: Unknown error 523 Using "cvs -q up -P -d": cvs update: cannot remove old_public_html/rfq: Unknown error 523 cvs update: cannot remove old_public_html/reporting: Unknown error 523 cvs update: cannot remove old_public_html/punchout: Unknown error 523 cvs update: cannot remove old_public_html/premium_content: Unknown error 523 cvs update: cannot remove old_public_html/customers: Unknown error 523 cvs update: cannot remove old_public_html/active_markets: Unknown error 523 cvs update: cannot remove old_public_html/Templates: Unknown error The directory old_public_html was removed log ago. Why is it showing up again now? I have an open case with NetApp about this issue but I figured I'd ask here to see if anyone else has experienced the same problem. If I check out to a non-NFS mounted directory, there are no errors. Same with update. Thanks in advance for any input. --Adam ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: sccs2rcs to perl
Michael Sterrett -Mr. Bones.- writes: > > I see a problem with the CVS code as distributed. That is, it has > a single csh script which is both slow and makes the CVS code-base > depend on an additional unix "utility" when it doesn't have to. > I believe I addressed both of these problems with my re-write of the > script in perl. I've announced it on the info-cvs list (a couple > of times now) and I'd like to make it available via FTP in the CVS > distribution if I could just get some cooperation from you, Derek or > one of the other silent CVS developers. Anybody with sccs, CVS, make, and perl almost certainly already has csh, too. The fact that the existing script is slow is irrelevant -- you generally convert your files just once, who cares whether it takes one hour or two? Perl scripts of any complexity are notorious for only running right on the exact version of perl they were written on and, so far as I can tell, your script has not been tested by anyone other than you. And given the stunning lack of interest shown here, it seems that no one really cares. So, while I'm sure you think it's wonderful and it sounds like it was a big benefit to you, I don't any value to adding it to the CVS distribution. -Larry Jones I always send Grandma a thank-you note right away. ...Ever since she sent me that empty box with the sarcastic note saying she was just checking to see if the Postal Service was still working. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: sccs2rcs to perl
On Thu, 7 Mar 2002, Larry Jones wrote: > Anybody with sccs, CVS, make, and perl almost certainly already has csh, Well, I don't - at least, I wouldn't if I didn't have to because CVS depends on csh *only* because of the sccs2rcs csh script. I'd love to remove csh from my system, but that would break dependencies (which is primarily why I re-wrote it in the first place). > And given the stunning lack of interest shown here, it seems that > no one really cares. So, while I'm sure you think it's wonderful and it > sounds like it was a big benefit to you, I don't any value to adding it > to the CVS distribution. Ok, let me try another idea on you then. Given the stunning lack of interest which, I admit certainly seems evident, how would you feel about removing the sccs2rcs script from the CVS distribution? That'd make me just as happy. All future CVS distribution gets smaller and you won't have to deal with any future bugs in the sccs2rcs script (which I see you had to patch a couple of times in the last year) -- everybody comes out a winner. Michael Sterrett -Mr. Bones.- [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: sccs2rcs to perl
[ On Thursday, March 7, 2002 at 16:46:04 (-0500), Michael Sterrett -Mr. Bones.- wrote: ] > Subject: Re: sccs2rcs to perl > > I see a problem with the CVS code as distributed. That is, it has > a single csh script which is both slow and makes the CVS code-base > depend on an additional unix "utility" when it doesn't have to. Well, it's only a contributed utility, not a core part of the CVS code as distributed. > I believe I addressed both of these problems with my re-write of the > script in perl. No, you did not. Only a translation to POSIX Shell or C would have addressed both problems. While the translation to perl may have made the script run faster, it only changed the reliance on one semi-standard tool to another less standard tool (perl is neither commonly available on all unix platforms, nor is it terribly small and fast, though it may be faster than csh). -- Greg A. Woods +1 416 218-0098; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Planix, Inc. <[EMAIL PROTECTED]>; VE3TCP; Secrets of the Weird <[EMAIL PROTECTED]> ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: sccs2rcs to perl
On Thu, 7 Mar 2002, Greg A. Woods wrote: > [ On Thursday, March 7, 2002 at 16:46:04 (-0500), Michael Sterrett -Mr. Bones$ > > Subject: Re: sccs2rcs to perl > > > > I see a problem with the CVS code as distributed. That is, it has > > a single csh script which is both slow and makes the CVS code-base > > depend on an additional unix "utility" when it doesn't have to. > > Well, it's only a contributed utility, not a core part of the CVS code > as distributed. All the Linux distributions I have access too include sccs2rcs as part of the CVS package because it is distributed as part of the CVS tar ball. Because of that, I consider it "part of CVS". > > I believe I addressed both of these problems with my re-write of the > > script in perl. > > No, you did not. Only a translation to POSIX Shell or C would have > addressed both problems. Sorry, but I disagree. There are already a number of perl scripts in the contrib directory so the package as a whole depends on perl already. I don't think you can argue that I've not reduced the number of dependencies for the CVS package. Michael Sterrett -Mr. Bones.- [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: sccs2rcs to perl
[ On Thursday, March 7, 2002 at 17:21:08 (-0500), Michael Sterrett -Mr. Bones.- wrote: ] > Subject: Re: sccs2rcs to perl > > Well, I don't - at least, I wouldn't if I didn't have to because CVS > depends on csh *only* because of the sccs2rcs csh script. I'd love to > remove csh from my system, but that would break dependencies (which is > primarily why I re-wrote it in the first place). I removed csh from almost all of my systems long ago. I still have no interest in re-writing sccs2rcs into perl though :-) (I don't think I would ever use sccs2rcs.csh either -- I'd write my own conversion tool in POSIX shell if I had to, even though it would be trivial for me to either install csh again or find a machine where it is still present and working) > Ok, let me try another idea on you then. Given the stunning lack of > interest which, I admit certainly seems evident, how would you feel about > removing the sccs2rcs script from the CVS distribution? That'd make me > just as happy. All future CVS distribution gets smaller and you won't have > to deal with any future bugs in the sccs2rcs script (which I see you had to > patch a couple of times in the last year) -- everybody comes out a winner. I wouldn't have any objection to that! ;-) -- Greg A. Woods +1 416 218-0098; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Planix, Inc. <[EMAIL PROTECTED]>; VE3TCP; Secrets of the Weird <[EMAIL PROTECTED]> ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: sccs2rcs to perl
[ On Thursday, March 7, 2002 at 18:06:22 (-0500), Michael Sterrett -Mr. Bones.- wrote: ] > Subject: Re: sccs2rcs to perl > > All the Linux distributions I have access too include sccs2rcs as part > of the CVS package because it is distributed as part of the CVS tar ball. > Because of that, I consider it "part of CVS". Unless you have SCCS files you wouldn't even know about it -- it's hardly a "part of CVS", especially since it's explicitly only included in the "contrib" sub-directory. > Sorry, but I disagree. There are already a number of perl scripts in the > contrib directory so the package as a whole depends on perl already. That's also irrelevant. You need to consider that the things in the "contrib" subdirectory are individual stand-alone things -- not related to each other (well, there are some that are related to each other, but most are completly independent), and only minimally related to CVS (sccs2rcs is only related very indirectly in that the RCS files it creates can be used by CVS). CVS itself, as a whole, does not depend on perl in any what whatsoever. > I don't think you can argue that I've not reduced the number of > dependencies for the CVS package. The "contrib" things are not really a part of the CVS package -- they're just a collection of things that were contributed but explicitly _not_ added to the package proper. -- Greg A. Woods +1 416 218-0098; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Planix, Inc. <[EMAIL PROTECTED]>; VE3TCP; Secrets of the Weird <[EMAIL PROTECTED]> ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: sccs2rcs to perl
On Thu, 7 Mar 2002, Greg A. Woods wrote: > I removed csh from almost all of my systems long ago. Ah, I envy you. :-) I refuse to ignore the package dependencies on my systems though... > I still have no interest in re-writing sccs2rcs into perl though :-) Well, I did it for two reasons: 1. the package dependencies (which I guess you don't mind ;-)) 2. I have a bunch of SCCS directories I need to convert to RCS and the csh version of the script is way too slow. > (I don't think I would ever use sccs2rcs.csh either -- I'd write my own > conversion tool in POSIX shell if I had to, even though it would be > trivial for me to either install csh again or find a machine where it is > still present and working) Ah, someone who dislikes csh even more than I do. > > I wouldn't have any objection to that! ;-) Great! Two votes for... Michael Sterrett -Mr. Bones.- [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: sccs2rcs to perl
[ On Thursday, March 7, 2002 at 18:40:03 (-0500), Michael Sterrett -Mr. Bones.- wrote: ] > Subject: Re: sccs2rcs to perl > > 2. I have a bunch of SCCS directories I need to convert to RCS and the >csh version of the script is way too slow. Is? "was"? :-) Why convert from SCCS? I don't have any larger projects managed by SCCS, but for all the small ones I have there's not much point to changing over to RCS (or CVS) -- I just keep using SCCS :-) -- Greg A. Woods +1 416 218-0098; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Planix, Inc. <[EMAIL PROTECTED]>; VE3TCP; Secrets of the Weird <[EMAIL PROTECTED]> ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Strange errors when checking out to NFS-mounted home directories
On Thu, Mar 07, 2002 at 02:32:24PM -0800, Adam McKenna wrote: > At work, we are getting strange errors when checking out to our home > directories which are mounted via NFS from a Network Appliance. > > The errors seem to occur when checking out specific tags, but mostly when > running an update with both the "-P" and "-d" flags, such as "cvs -q up -P > -d". > > Here is a sample of the error messages: > > Using "cvs co -r tag austin": > cvs checkout: cannot remove austin/old_public_html/customers: Unknown error > 523 The first step is to find out what NetApp's error number 523 is ... If they have an accessible /usr/include/sys/errno.h or whatever, you're in luck. If not, RTFM, or wait for their support people to get back to you. > Using "cvs -q up -P -d": > cvs update: cannot remove old_public_html/rfq: Unknown error 523 > cvs update: cannot remove old_public_html/reporting: Unknown error 523 > > The directory old_public_html was removed log ago. Why is it showing up > again now? Because of the "-d" option. If by "removed" you mean that the files were "cvs rm"ed, then the directory (and the files) are still present in the repo. It wouldn't surprise me if "cvs update -dP" does things suboptimally -- creates each directory, then deletes it again if it ends up empty. -- | | /\ |-_|/ > Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / "Outlook not so good." That magic 8-ball knows everything! I'll ask about Exchange Server next. - Anonymous ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: renaming under CVS
>--- Forwarded mail from [EMAIL PROTECTED] >--- Paul Sander <[EMAIL PROTECTED]> wrote: >> >> Permissions on a directory basis are tough if >> files >> >> are linked to >> >> multiple directories that have different >> >> permissions. >> >> >I am satisfied with how permissioning is done now >> (ie >> >per-directory). >> >> Okay, but this will become a problem depending on >> how the containers >> are stored. If the files move but the containers >> don't, then setting >> directory-wide permissions properly will become >> difficult. >It just occurred to me that if the archive files >didn't live within the repo directory (as I had >intended), then the permissions on the archive files >would be extremely important (and probably impossible >to manage). I'll have to rethink this, but as of now, >it looks like the archive file will need to live >within the repo directory and that a repo-wide archive >location mapping will be needed. >> Example: >> >> Begin with contents of directory /a/b, namely, files >> c and d. They >> have particular permissions. Now move file c do >> directory /e/f. >> Suppose that directory has a different group >> ownership. How are the >> permissions of file c affected by the move, and will >> the result be >> what the user expects? >The only archive file permissions that matter are the >read and execute permissions. The execute permissions >are inherited by the archived file. Those that need >to work with the archive file (ie checkin, checout, >...) will need read permissions. Keep in mind that "permissions" include not only the file's mode, but also its user and group ownerships, plus whatever additional mechanism (e.g. ACLs) are provided by the operating system. As files propagate around the repository then the permissions will have to behave in ways that the user expects that are not necessarily easy to implement. >Assuming that a file is moved from one directory to >another with a different group, and the SGID bit is >set on the repo directory, the archive file will be >moved adopting the new group. An update to the >repo-wide archive location mapping will also be >necessary. How do you expect this to affect retrieval by tag or datestamp? The person performing that task may not be a member of the new group. >> Now create directories /a/g and /e/g, where "g" is >> really the same >> directory, but shared between two projects. Move >> file d into directory >> g. It should appear in both projects, but what are >> its permissions? >Sharing of directories will no longer be supported >since "complex" module definitions will no longer be >supported. What about this case? mod-a a mod-b a/b Anyway, disallowing this type of sharing and that in the example above is not acceptable to me. Code reuse by sharing source code isn't going away any time soon (no matter that the buildmeisters want it to), and the version control system can't get in the way of that. Also note that retrieval by tag or datestamp is required to retain the old shape of the tree. Making that work means that a single RCS file maps to multiple locations in workspaces anyway, so the kind of sharing that I demand should come for free. >> My concern here is that what we today think of as >> modules would never >> disappear without substantial effort. Consequently, >> "cvs rm" shouldn't >> be permitted in the top level. >I still don't understand. Can you give an example? My thought had been that if a project reaches the end of its life, should a user be permitted to delete its definition from the top level? Re-thinking this, I don't think it matters. It's still retrievable by tag or datestamp, and the effect is no different from moving the project into a new directory and removing it from there. The question remaining is how to query the system for existing modules, because the ones contained at the top level of the repository are really just a subset of the total possible. There's also the issue of ambiguity of names, because a project might be removed and a new one created with the same name. >> >> Also, I was considering using a special container >> >> name of "0" to locate >> >> the top-level definitions. >> >> >"0" (well, more likely 64 0's) sounds good to me. >> >There also needs to be a way to add/remove from >> this >> >top-level list. What do you think of switches to >> >"add" and "rm"? >> >> I figured it would be treated like any other >> directory, with the >> exception that "rm" would be disallowed. I have no >> problem with >> people adding new projects, but there should be a >> trigger on "add" >> to enforce local policies. >I think the trigger architecture needs an overhaul and >since the existing one can be used to enforce "add" >policies, I'd rather concentrate on the meaty issues >at hand. >> >Also, I'm not a fan of completely wiping out >> archive >> >files, but I can see a need for it. This also >> needs >> >more consideration. >> >> I'm also happy to leave them the
Re: Major cvs surgery, need suggestions
"David A. Desrosiers" <[EMAIL PROTECTED]> writes: > > What I have found which works, but is very tedious to do is: > > I disagree. Doing the cvs remove/add locally is the most harmful to my > goals (preserve history, changes, and revision per file). Using the > process I've shown above seems to work perfectly, except it's very tedious > to plod through so many files and directories. Let's assume that you took the time to go through this procedure. How can you ever be sure that you didn't make a mistake along the way? After you are done with this procedure, you would have to build all past versions of your projects that have been released to customers and for each of these versions, you would have to verify that you are getting the same files/binaries as the ones you had released in the past. Too much work for too little return, I think... -- Timur Aydin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
ÑûÇ뺯
Title: ÐÜèÎÀÊ¿·´²¡¶¾£¬Ò»Âíµ±ÏÈ£¡ ¡¡Èô²»ÄÜÕý³£ä¯ÀÀ´ËÓʼþ£¬Çëµ¥»÷ÕâÀï Ñû¡¡Çë¡¡º¯ Ç×°®µÄÅóÓÑ£¬ 2002ÄêÂíÄêÒÁʼ£¬·À²¡¶¾Êг¡µÄÖ÷Á¦¾ü¹ú¼ÊÖøÃûµÄ¼ÆËã»ú°²È«²úÆ·Èí¼þ¹«Ë¾ÐÜèÈí¼þЯ ͬȫÇòÐÂÆ· Panda Antivirus Enterprise Suite(PAES)ºÍPanda Perimeter Scan (PPS)¡£ÆëÁ¦Óë¹úÄÚ·½Õý¿Æ¼¼ÆìÏÂרӪÈí ¼þÒµÎñµÄ·½ÕýÈí¼þÈ«ÃæºÏ×÷£¬Ò»Âíµ±ÏȵضáµÃÁËÄê³õºÃʱ»ú£¬²¢Óû´òÔì2002ÄêÈí¼þ½çÐÂÆæ¼£¡£½ìʱ£¬ ÐÜèºÍ·½Õý½«³ÏÖ¿ÑûÇëÄúÀ´²Î¼ÓÐÜèÎÀÊ¿ºÍ·½Õý¾«ÐÄΪÄú×¼±¸µÄÉϺ£¡¢±±¾©Á½µØºÏ×÷¼ô²ÊÒÇʽ ôßÈ«ÇòÐÂÆ··¢²¼¡£Ê±¼ä·Ö±ð¶¨ÓÚ2002Äê3ÔÂ26ÈÕ¡¢3ÔÂ29ÈÕ,»¶ÓÄú½ìʱ¹âÁÙ¡£Í¬Ê±£¬ÐÜèºÍ·½Õý½«Æô¶¯ È«¹úÊ®¸ö³ÇÊеÄƽ̨£¬À´·¢ÆðÒ»´Îºìºì»ð»ðµÄÐÂƷչʾÍòÀïÐС£ÐÜèÎÀÊ¿ÄÜÑûÇëµ½Äú½«ÊÇÎÒÃǵÄÈÙÐÒ ¡£ÌرðµÄʱ¼ä£¬ÌرðµÄµØµã£¬ÆÚ´ý×ÅÌرðµÄÄ㣬Çë°ÑÕâ¸öʱ¼ä±£Áô¸øÎÒÃÇ°É¡£ ÎÒÃǽ«ÔÚÉϺ£(3.26)£¬±±¾©(3.29)£¬¹ãÖÝ(4.2)£¬ºþÄÏ(4.15)£¬ÄϾ©(4.19)£¬º¼ÖÝ(4.16)£¬Î÷°²(4.26)£¬ ³É¶¼(4.23)£¬ÉòÑô(4.12)£¬¼ÃÄÏ(4.9)µÈ´ýÄúµÄ¹âÁÙ£¡ ͬʱ£¬¸ÐлÄú¼°¹ó¹«Ë¾Ò»Ö±ÒÔÀ´¶ÔÐÜèÈí¼þµÄÖ§³ÖºÍÐÅÀµ¡£ ÐÜèÈí¼þ£¨Öйú£©ÓÐÏÞ¹«Ë¾ ÉϺ£Õ¹»á£º ʱ¼ä£º2002Äê3ÔÂ26ÈÕ µØµã£ºÉϺ£ÊÐÆÖ¶«ÊÀ¼Í´óµÀ88ºÅ½ðï´óÏà ¡¡½ðï½ðÔôó¾Æµê£¨Èº·¿£©¶þÂ¥Ñç»áÌü¢òÇø ±±¾©Õ¹»á£º ʱ¼ä£º2002Äê3ÔÂ29ÈÕ µØµã£º±±¾©Êк£µíÇøÖª´ºÂ·76ºÅ´ä¹¬·¹µê¶þÂ¥¶à¹¦ÄÜÌü At Panda Software we respect your privacy. If you do not want to receive further communications, click here. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
ÑûÇ뺯
Title: ÐÜèÎÀÊ¿·´²¡¶¾£¬Ò»Âíµ±ÏÈ£¡ ¡¡Èô²»ÄÜÕý³£ä¯ÀÀ´ËÓʼþ£¬Çëµ¥»÷ÕâÀï Ñû¡¡Çë¡¡º¯ Ç×°®µÄÅóÓÑ£¬ 2002ÄêÂíÄêÒÁʼ£¬·À²¡¶¾Êг¡µÄÖ÷Á¦¾ü¹ú¼ÊÖøÃûµÄ¼ÆËã»ú°²È«²úÆ·Èí¼þ¹«Ë¾ÐÜèÈí¼þЯ ͬȫÇòÐÂÆ· Panda Antivirus Enterprise Suite(PAES)ºÍPanda Perimeter Scan (PPS)¡£ÆëÁ¦Óë¹úÄÚ·½Õý¿Æ¼¼ÆìÏÂרӪÈí ¼þÒµÎñµÄ·½ÕýÈí¼þÈ«ÃæºÏ×÷£¬Ò»Âíµ±ÏȵضáµÃÁËÄê³õºÃʱ»ú£¬²¢Óû´òÔì2002ÄêÈí¼þ½çÐÂÆæ¼£¡£½ìʱ£¬ ÐÜèºÍ·½Õý½«³ÏÖ¿ÑûÇëÄúÀ´²Î¼ÓÐÜèÎÀÊ¿ºÍ·½Õý¾«ÐÄΪÄú×¼±¸µÄÉϺ£¡¢±±¾©Á½µØºÏ×÷¼ô²ÊÒÇʽ ôßÈ«ÇòÐÂÆ··¢²¼¡£Ê±¼ä·Ö±ð¶¨ÓÚ2002Äê3ÔÂ26ÈÕ¡¢3ÔÂ29ÈÕ,»¶ÓÄú½ìʱ¹âÁÙ¡£Í¬Ê±£¬ÐÜèºÍ·½Õý½«Æô¶¯ È«¹úÊ®¸ö³ÇÊеÄƽ̨£¬À´·¢ÆðÒ»´Îºìºì»ð»ðµÄÐÂƷչʾÍòÀïÐС£ÐÜèÎÀÊ¿ÄÜÑûÇëµ½Äú½«ÊÇÎÒÃǵÄÈÙÐÒ ¡£ÌرðµÄʱ¼ä£¬ÌرðµÄµØµã£¬ÆÚ´ý×ÅÌرðµÄÄ㣬Çë°ÑÕâ¸öʱ¼ä±£Áô¸øÎÒÃÇ°É¡£ ÎÒÃǽ«ÔÚÉϺ£(3.26)£¬±±¾©(3.29)£¬¹ãÖÝ(4.2)£¬ºþÄÏ(4.15)£¬ÄϾ©(4.19)£¬º¼ÖÝ(4.16)£¬Î÷°²(4.26)£¬ ³É¶¼(4.23)£¬ÉòÑô(4.12)£¬¼ÃÄÏ(4.9)µÈ´ýÄúµÄ¹âÁÙ£¡ ͬʱ£¬¸ÐлÄú¼°¹ó¹«Ë¾Ò»Ö±ÒÔÀ´¶ÔÐÜèÈí¼þµÄÖ§³ÖºÍÐÅÀµ¡£ ÐÜèÈí¼þ£¨Öйú£©ÓÐÏÞ¹«Ë¾ ÉϺ£Õ¹»á£º ʱ¼ä£º2002Äê3ÔÂ26ÈÕ µØµã£ºÉϺ£ÊÐÆÖ¶«ÊÀ¼Í´óµÀ88ºÅ½ðï´óÏà ¡¡½ðï½ðÔôó¾Æµê£¨Èº·¿£©¶þÂ¥Ñç»áÌü¢òÇø ±±¾©Õ¹»á£º ʱ¼ä£º2002Äê3ÔÂ29ÈÕ µØµã£º±±¾©Êк£µíÇøÖª´ºÂ·76ºÅ´ä¹¬·¹µê¶þÂ¥¶à¹¦ÄÜÌü At Panda Software we respect your privacy. If you do not want to receive further communications, click here. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
ÇáÇáËÉËÉÓζػÍ
Title: Untitled Document ¶Ø»ÍÂÃÓηþÎñÖÐÐÄ2002Ä깫¸æ¼°³£¹æÏß· (×îб¨¼Û) ¡¡ 2002ÄêË¿³ñ֮·ÎÄ»¯Ö®Âà Ëæ׏ú¼ÒÎ÷²¿´ó¿ª·¢µÄʵʩ£¬Î÷²¿ÂÃÓÎÒ²Ô½À´Ô½ÈÈ£¬ÓÐ׏ÅÀÏÎÄÃ÷ÀúÊ·µÄ˿·¹ÅµÀÒ²ÈÕÒæÎüÒýÖÐÍâÓο͵ÄÄ¿¹â¡£Ë³Ó¦ÕâÖÖÇ÷ÊÆ£¬Öйú˿·ÂÃÓÎÍø¡¢¶Ø»ÍÖ®´°ºÍ¶Ø»ÍÂÃÓÎÈÈÏß,ÓÚ½ñÄê¡ÖØÍƳö¡°2002ÄêË¿³ñ֮·ÎÄ»¯Ö®Âá±£¬Ö¼ÔÚÈÃË¿³ñ֮·µÄ¹ÅÀÏÎÄÃ÷³ä·ÖµÄÕ¹ÏÖÔÚÊÀÈËÃæÇ°¡£ Ö÷ÌâÄÚÈÝ ¸ÐÊÜ´óÄ®¸ê±ÚµÄ²ÔÁ¹ÓëÐۻ룻̽Ѱ˿·¹ÅµÀǧÄê»Ô»Í¡¢Ç§Äê³Á¼ÅµÄÃØÃÜ£»ÌåÑéÎ÷±±ÉÙÊýÃñ×åµÄÎÄ»¯Éú»îºÍÃñ×å·çÇ飻ÁìÂԶػÍÎÄ»¯µÄÉñÃزÓÀᢲ©´ó¾«ÉñöÌý¹ÅÕ½³¡½ð¸êÌúÂíµÄÀúÊ·»ØÒô£»×ÌÉú×íÎÔɳ³¡µÄºÀÂõÆø¸Å¡£ ÑØ׏ÅÀϵÄË¿³ñ֮·£¬Ñ°ÕÒÀúÊ·ÎÄÃ÷µÄ×ã¼££º´óÑãËþµÄׯÖØ£¬Âó»ýɽµÄͦ°Î£¬»ÆºÓË®³µµÄÐúÏù£¬À²·Àã˵ÄËàÄ£¬Âí̤·ÉÑàµÄÉñÆ棬¼ÎÓø¹ØµÄÐÛ׳£¬ÔÂÑÀȪµÄÉñÃØ£¬Äª¸ß¿ßµÄºñÖØ£¬ÇຣºþµÄÃÀÀö£¬Ëþ¶û˵ĺê࣬ͳ·¬µÄÈÈÇ飬Ìì³ØµÄÓÕ»óÀúÊ·ÓëÏÖʵ¶¼½«Ò»Ò»Õ¹ÏÖÔÚÄúµÄÃæÇ°¡£ ¾«Ñ¡Ïß· À¼ÖݼÎÓø¹Ø¶Ø»Íͳ·¬ÎÚ³ľÆë»ð³µ¾ÅÈÕÓÎ À¼ÖݶػÍͳ·¬ÎÚ³ľÆëµ¥·ÉÆßÈÕÓÎ ÎÚ³ľÆëͳ·¬¶Ø»Í¼ÎÓø ¹ØÀ¼ÖÝÎ÷°²Ê®Ò»ÈÕÓÎ À¼ÖÝÎ÷ÄþÕÅÒ´¼ÎÓø¹Ø¶Ø»Íͳ·¬ÎÚ³ľÆë À¼ÖÝ---ÁÙÏÄ---ÏĺÓ---¼ÎÓø¹Ø---¶Ø»Í---ͳ·¬---ÎÚ³ľÆëÊ®ÈÕÓÎ Òø´¨À¼ÖÝÇຣÎåÈÕÓÎ À¼ÖÝÀ²·ÀãË»ÆÁú¾ÅÕ¯¹µÆßÈÕÓÎ À¼ÖÝ--ÎäÍþ--ÕÅÒ´--¾ÆȪ--¼ÎÓø¹Ø--¶Ø»Í--ͳ·¬-ÎÚ³ľÆë¾ÅÈÕÓÎ ÎÚ³ľÆëͳ·¬¶Ø»Í¼ÎÓø¹ØÕÅÒ´Î÷Äþ¾ÅÈÕÓÎ Î÷°²¼ÎÓø¹Ø¶Ø»Íͳ·¬ÎÚ³ľÆë°ËÈÕÓÎ ¶Ø»Í--Çຣºþ--Ñκþ--¸ñ¶ûľ--ÌƹÅÀɽ--ÀÈø--ÈÕ¿¦Ôò--Æû³µÊ®ÈÕÓÎ ÉϺ£¼ÎÓø¹Ø¶Ø»Íͳ·¬ÎÚ³ľÆë°ËÈÕÓÎ ÎÄ»¯ÌØÉ«»î¶¯ 1. Ãɹš¢¹þÈø¿ËÉÙÊýÃñ×å¸èÎè±íÑݼ°Áª»¶»î¶¯£» 2. ¿¾³ÔÈ«Ñò£¬ºÈÇàïý¾Æ£¬¸ÐÊÜÎ÷±±È˵ĺÀÂõ£¬×ÌÉú¡°×íÎÔɳ³¡¡±µÄÆø¸Å£» 3. ס½øÃɹŰü£¬ÓëÃñ×åͬ°û¹²½øÍí²Í£¬¾´Ï×¹þ´ï£¬ºÏÓ°ÁôÄ 4. ñöÌý¶Ø»Í¹ÅÀÖÑÝ×ࣻ 5. ¶Ø»Íóô»ðÍí»á£¬ÖÐÍâÓοʹóÁª»¶£» 6. Æ·³¢¸÷µØ·çζÌØÉ«²Í£» 7. ÁÔÆæÂÃÓΣ¬Ä§¹í³Ç̽ÏÕ£» 8. ÆïÂí¡¢Éä¼ý£¬²ÎÓë¹ÅÕ½Õù³¡Ã棻 9. Ò¹ËÞ¸ê±Ú£¬ÓÃÐĸÐÊܲÔÁ¹ÓëÉñÆ棻 10. ÓοÍÒªÇóµÄÆäËûÌرð»î¶¯¡£ ¡¡À´°É£¬Ç×°®µÄÅóÓÑ£¡Î÷²¿»¶ÓÄú£¬Ë¿³ñ֮·»¶ÓÄú£¬¶Ø»ÍÂÃÓηþÎñÖÐÐÄ»¶ÓÄú£¡ ¶Ø»Í¶þÈÕÓÎ AÏߣºµÚÒ»Ì죺¶Ø»ÍÕ¾½Ó³µ´Î T53 T69 T189 1043´Î Öвͺ󸰶ػÍÊÐÇø¡¢ÏÂÎ磺Ãùɳɽ¡¢ÔÂÑÀȪ¡¢À×ÒôË¡¢Íí²Íºó¶Ø»ÍÒ¹ÊС¢Ë޶ػͣ» µÚ¶þÌ죺Ôç²Íºó²Î¹ÛĪ¸ß¿ß¡¢Ê¯¿ßÒÕÊõ³ÂÁÐÖÐÐÄ¡¢²Ø¾¶´ÎÄÎï³ÂÁйݡ¢Öвͺó²Î¹Û·ÂËιųǡ¢Íí²ÍºóËͶػͻð³µÕ¾¡£ BÏߣºµÚÒ»Ì죺¶Ø»ÍÕ¾½Ó ³µ´Î T53 T69 T189 1043´Î Öвͺ󸰶ػÍÊÐÇø¡¢ÏÂÎ磺Ãùɳɽ¡¢ÔÂÑÀȪ¡¢ÃñËײ©Îï¹Ý¡¢À×ÒôË£»Íí²Íºó¶Ø»ÍÒ¹ÊÐËÞ¶Ø»Í µÚ¶þÌ죺Ôç²Íºó²Î¹ÛĪ¸ß¿ß¡¢Ê¯¿ßÒÕÊõ³ÂÁÐÖÐÐÄ¡¢²Ø¾¶´ÎÄÎï³ÂÁйݡ¢Öвͺó²Î¹ÛÊв©Îï¹Ý¡¢·ÂËιųǡ¢Íí²ÍºóËͶػͻð³µÕ¾ ±ê×¼£º10ÈËÒÔÉϳÉÍÅ·ÑÓÃÈçÏ£º Ïß· ×Û·Ñ ·¿·Ñ ²Í·Ñ ½»Í¨·Ñ ÃÅƱ·Ñ ºÏ¼Æ AÏß 40/ÈË 60/ÈË/Ìì 90/ÈË 100/ÈË 155/ÈË 445Ôª/ÈË BÏß 40/ÈË 60/ÈË/Ìì 90/ÈË 100/ÈË 190/ÈË 480Ôª/ÈË ¡¡10ÈËÒÔÏÂ3ÈËÒÔÉϳÉÍÅ·ÑÓÃÈçÏ£º Ïß·
ÑûÇ뺯
Title: ÐÜèÎÀÊ¿·´²¡¶¾£¬Ò»Âíµ±ÏÈ£¡ ¡¡Èô²»ÄÜÕý³£ä¯ÀÀ´ËÓʼþ£¬Çëµ¥»÷ÕâÀï Ñû¡¡Çë¡¡º¯ Ç×°®µÄÅóÓÑ£¬ 2002ÄêÂíÄêÒÁʼ£¬·À²¡¶¾Êг¡µÄÖ÷Á¦¾ü¹ú¼ÊÖøÃûµÄ¼ÆËã»ú°²È«²úÆ·Èí¼þ¹«Ë¾ÐÜèÈí¼þЯ ͬȫÇòÐÂÆ· Panda Antivirus Enterprise Suite(PAES)ºÍPanda Perimeter Scan (PPS)¡£ÆëÁ¦Óë¹úÄÚ·½Õý¿Æ¼¼ÆìÏÂרӪÈí ¼þÒµÎñµÄ·½ÕýÈí¼þÈ«ÃæºÏ×÷£¬Ò»Âíµ±ÏȵضáµÃÁËÄê³õºÃʱ»ú£¬²¢Óû´òÔì2002ÄêÈí¼þ½çÐÂÆæ¼£¡£½ìʱ£¬ ÐÜèºÍ·½Õý½«³ÏÖ¿ÑûÇëÄúÀ´²Î¼ÓÐÜèÎÀÊ¿ºÍ·½Õý¾«ÐÄΪÄú×¼±¸µÄÉϺ£¡¢±±¾©Á½µØºÏ×÷¼ô²ÊÒÇʽ ôßÈ«ÇòÐÂÆ··¢²¼¡£Ê±¼ä·Ö±ð¶¨ÓÚ2002Äê3ÔÂ26ÈÕ¡¢3ÔÂ29ÈÕ,»¶ÓÄú½ìʱ¹âÁÙ¡£Í¬Ê±£¬ÐÜèºÍ·½Õý½«Æô¶¯ È«¹úÊ®¸ö³ÇÊеÄƽ̨£¬À´·¢ÆðÒ»´Îºìºì»ð»ðµÄÐÂƷչʾÍòÀïÐС£ÐÜèÎÀÊ¿ÄÜÑûÇëµ½Äú½«ÊÇÎÒÃǵÄÈÙÐÒ ¡£ÌرðµÄʱ¼ä£¬ÌرðµÄµØµã£¬ÆÚ´ý×ÅÌرðµÄÄ㣬Çë°ÑÕâ¸öʱ¼ä±£Áô¸øÎÒÃÇ°É¡£ ÎÒÃǽ«ÔÚÉϺ£(3.26)£¬±±¾©(3.29)£¬¹ãÖÝ(4.2)£¬ºþÄÏ(4.15)£¬ÄϾ©(4.19)£¬º¼ÖÝ(4.16)£¬Î÷°²(4.26)£¬ ³É¶¼(4.23)£¬ÉòÑô(4.12)£¬¼ÃÄÏ(4.9)µÈ´ýÄúµÄ¹âÁÙ£¡ ͬʱ£¬¸ÐлÄú¼°¹ó¹«Ë¾Ò»Ö±ÒÔÀ´¶ÔÐÜèÈí¼þµÄÖ§³ÖºÍÐÅÀµ¡£ ÐÜèÈí¼þ£¨Öйú£©ÓÐÏÞ¹«Ë¾ ÉϺ£Õ¹»á£º ʱ¼ä£º2002Äê3ÔÂ26ÈÕ µØµã£ºÉϺ£ÊÐÆÖ¶«ÊÀ¼Í´óµÀ88ºÅ½ðï´óÏà ¡¡½ðï¿Ôôó¾Æµê£¨Èº·¿£©¶þÂ¥Ñç»áÌü¢òÇø ±±¾©Õ¹»á£º ʱ¼ä£º2002Äê3ÔÂ29ÈÕ µØµã£º±±¾©Êк£µíÇøÖª´ºÂ·76ºÅ´ä¹¬·¹µê¶þÂ¥¶à¹¦ÄÜÌü At Panda Software we respect your privacy. If you do not want to receive further communications, click here. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
ÑûÇ뺯
Title: ÐÜèÎÀÊ¿·´²¡¶¾£¬Ò»Âíµ±ÏÈ£¡ ¡¡Èô²»ÄÜÕý³£ä¯ÀÀ´ËÓʼþ£¬Çëµ¥»÷ÕâÀï Ñû¡¡Çë¡¡º¯ Ç×°®µÄÅóÓÑ£¬ 2002ÄêÂíÄêÒÁʼ£¬·À²¡¶¾Êг¡µÄÖ÷Á¦¾ü¹ú¼ÊÖøÃûµÄ¼ÆËã»ú°²È«²úÆ·Èí¼þ¹«Ë¾ÐÜèÈí¼þЯ ͬȫÇòÐÂÆ· Panda Antivirus Enterprise Suite(PAES)ºÍPanda Perimeter Scan (PPS)¡£ÆëÁ¦Óë¹úÄÚ·½Õý¿Æ¼¼ÆìÏÂרӪÈí ¼þÒµÎñµÄ·½ÕýÈí¼þÈ«ÃæºÏ×÷£¬Ò»Âíµ±ÏȵضáµÃÁËÄê³õºÃʱ»ú£¬²¢Óû´òÔì2002ÄêÈí¼þ½çÐÂÆæ¼£¡£½ìʱ£¬ ÐÜèºÍ·½Õý½«³ÏÖ¿ÑûÇëÄúÀ´²Î¼ÓÐÜèÎÀÊ¿ºÍ·½Õý¾«ÐÄΪÄú×¼±¸µÄÉϺ£¡¢±±¾©Á½µØºÏ×÷¼ô²ÊÒÇʽ ôßÈ«ÇòÐÂÆ··¢²¼¡£Ê±¼ä·Ö±ð¶¨ÓÚ2002Äê3ÔÂ26ÈÕ¡¢3ÔÂ29ÈÕ,»¶ÓÄú½ìʱ¹âÁÙ¡£Í¬Ê±£¬ÐÜèºÍ·½Õý½«Æô¶¯ È«¹úÊ®¸ö³ÇÊеÄƽ̨£¬À´·¢ÆðÒ»´Îºìºì»ð»ðµÄÐÂƷչʾÍòÀïÐС£ÐÜèÎÀÊ¿ÄÜÑûÇëµ½Äú½«ÊÇÎÒÃǵÄÈÙÐÒ ¡£ÌرðµÄʱ¼ä£¬ÌرðµÄµØµã£¬ÆÚ´ý×ÅÌرðµÄÄ㣬Çë°ÑÕâ¸öʱ¼ä±£Áô¸øÎÒÃÇ°É¡£ ÎÒÃǽ«ÔÚÉϺ£(3.26)£¬±±¾©(3.29)£¬¹ãÖÝ(4.2)£¬ºþÄÏ(4.15)£¬ÄϾ©(4.19)£¬º¼ÖÝ(4.16)£¬Î÷°²(4.26)£¬ ³É¶¼(4.23)£¬ÉòÑô(4.12)£¬¼ÃÄÏ(4.9)µÈ´ýÄúµÄ¹âÁÙ£¡ ͬʱ£¬¸ÐлÄú¼°¹ó¹«Ë¾Ò»Ö±ÒÔÀ´¶ÔÐÜèÈí¼þµÄÖ§³ÖºÍÐÅÀµ¡£ ÐÜèÈí¼þ£¨Öйú£©ÓÐÏÞ¹«Ë¾ ÉϺ£Õ¹»á£º ʱ¼ä£º2002Äê3ÔÂ26ÈÕ µØµã£ºÉϺ£ÊÐÆÖ¶«ÊÀ¼Í´óµÀ88ºÅ½ðï´óÏà ¡¡½ðï½ðÔôó¾Æµê£¨Èº·¿£©¶þÂ¥Ñç»áÌü¢òÇø ±±¾©Õ¹»á£º ʱ¼ä£º2002Äê3ÔÂ29ÈÕ µØµã£º±±¾©Êк£µíÇøÖª´ºÂ·76ºÅ´ä¹¬·¹µê¶þÂ¥¶à¹¦ÄÜÌü At Panda Software we respect your privacy. If you do not want to receive further communications, click here. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
ÑûÇ뺯
Title: ÐÜèÎÀÊ¿·´²¡¶¾£¬Ò»Âíµ±ÏÈ£¡ ¡¡Èô²»ÄÜÕý³£ä¯ÀÀ´ËÓʼþ£¬Çëµ¥»÷ÕâÀï Ñû¡¡Çë¡¡º¯ Ç×°®µÄÅóÓÑ£¬ 2002ÄêÂíÄêÒÁʼ£¬·À²¡¶¾Êг¡µÄÖ÷Á¦¾ü¹ú¼ÊÖøÃûµÄ¼ÆËã»ú°²È«²úÆ·Èí¼þ¹«Ë¾ÐÜèÈí¼þЯ ͬȫÇòÐÂÆ· Panda Antivirus Enterprise Suite(PAES)ºÍPanda Perimeter Scan (PPS)¡£ÆëÁ¦Óë¹úÄÚ·½Õý¿Æ¼¼ÆìÏÂרӪÈí ¼þÒµÎñµÄ·½ÕýÈí¼þÈ«ÃæºÏ×÷£¬Ò»Âíµ±ÏȵضáµÃÁËÄê³õºÃʱ»ú£¬²¢Óû´òÔì2002ÄêÈí¼þ½çÐÂÆæ¼£¡£½ìʱ£¬ ÐÜèºÍ·½Õý½«³ÏÖ¿ÑûÇëÄúÀ´²Î¼ÓÐÜèÎÀÊ¿ºÍ·½Õý¾«ÐÄΪÄú×¼±¸µÄÉϺ£¡¢±±¾©Á½µØºÏ×÷¼ô²ÊÒÇʽ ôßÈ«ÇòÐÂÆ··¢²¼¡£Ê±¼ä·Ö±ð¶¨ÓÚ2002Äê3ÔÂ26ÈÕ¡¢3ÔÂ29ÈÕ,»¶ÓÄú½ìʱ¹âÁÙ¡£Í¬Ê±£¬ÐÜèºÍ·½Õý½«Æô¶¯ È«¹úÊ®¸ö³ÇÊеÄƽ̨£¬À´·¢ÆðÒ»´Îºìºì»ð»ðµÄÐÂƷչʾÍòÀïÐС£ÐÜèÎÀÊ¿ÄÜÑûÇëµ½Äú½«ÊÇÎÒÃǵÄÈÙÐÒ ¡£ÌرðµÄʱ¼ä£¬ÌرðµÄµØµã£¬ÆÚ´ý×ÅÌرðµÄÄ㣬Çë°ÑÕâ¸öʱ¼ä±£Áô¸øÎÒÃÇ°É¡£ ÎÒÃǽ«ÔÚÉϺ£(3.26)£¬±±¾©(3.29)£¬¹ãÖÝ(4.2)£¬ºþÄÏ(4.15)£¬ÄϾ©(4.19)£¬º¼ÖÝ(4.16)£¬Î÷°²(4.26)£¬ ³É¶¼(4.23)£¬ÉòÑô(4.12)£¬¼ÃÄÏ(4.9)µÈ´ýÄúµÄ¹âÁÙ£¡ ͬʱ£¬¸ÐлÄú¼°¹ó¹«Ë¾Ò»Ö±ÒÔÀ´¶ÔÐÜèÈí¼þµÄÖ§³ÖºÍÐÅÀµ¡£ ÐÜèÈí¼þ£¨Öйú£©ÓÐÏÞ¹«Ë¾ ÉϺ£Õ¹»á£º ʱ¼ä£º2002Äê3ÔÂ26ÈÕ µØµã£ºÉϺ£ÊÐÆÖ¶«ÊÀ¼Í´óµÀ88ºÅ½ðï´óÏà ¡¡½ðï½ðÔôó¾Æµê£¨Èº·¿£©¶þÂ¥Ñç»áÌü¢òÇø ±±¾©Õ¹»á£º ʱ¼ä£º2002Äê3ÔÂ29ÈÕ µØµã£º±±¾©Êк£µíÇøÖª´ºÂ·76ºÅ´ä¹¬·¹µê¶þÂ¥¶à¹¦ÄÜÌü At Panda Software we respect your privacy. If you do not want to receive further communications, click here. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
