Fwolf wrote:
> 能否考虑用配置文件分开？这样就不用开分支了。
>   
将其集中成为可配置选项是我们一开始采用的思路，但是发现增加了代码维护量，
原因是很多选项是除了B公司以外，没有人会选中采用的，加上为此在选项模块增
加了钩子，钩子多了也不易管理，C公司常常觉得系统无法控制，主要程序员也和
我来了一次不怎么愉快的谈话，认为可选东西太多了。比如为啤酒节准备的那个功
能，显然除了B公司其它人不会再用了，增加一个啤酒节选项很怪的。
> On Sat, Jun 07, 2008 at 07:08:35PM +0800, Zhang Weiwu wrote:
>   
>> Sutra Zhou wrote:
>>     
>>> 为什么会有20个修改不应该merge到主干呢？
>>> 是因为已经merge过了，还是这个修改不需要了？
>>> 如果这个修改不需要了，是需要人工判断一下，如果已经merge过了，再次merge
>>> 的时候根本看不到它了。
>>>       
>> 举一个例子：B公司内部使用Lotus Notes 6.x，不支持UTF-8，所以无法阅读收到
>> 的系统通知信。但是所有其它的客户都没有这种情况（有的是用新版的Lotus
>> Notes），而B公司不打算花钱升级。所以b分支上事先将电子邮件转为HTML格式，
>> 使用entities表示特殊字符。这变化是逆潮流而动，不应该 merge到主干。这种事
>> 其实挻多的，我还可以找出好些例子呢。
>>     
>>> 在 2008-6-7，下午7:03， Zhang Weiwu 写道：
>>>
>>>       
>>>> Zhang Weiwu wrote:
>>>>         
>>>>> Sutra Zhou wrote:
>>>>>
>>>>>           
>>>>>> 没必要每次都merge，如果每次提交到分支的代码都需要merge到主干，那我觉得
>>>>>> 项目的管理是有问题的。
>>>>>>
>>>>>> 我觉得在分支生命周期结束了的时候再merge不迟，主干上的代码一般都比较激
>>>>>> 进地在开发新功能，如没有必要，压根没有必要合并上来。
>>>>>>
>>>>>>
>>>>>>             
>>>> 报歉，我误解了你的问题。我以为你是说为何将生命周期安排得这样短。
>>>>
>>>> 在分支生命周期结束了的时候再merge的问题是，在分支生命周期里一共有120
>>>> 个修改，其中100个应该合并到主分支上，20个不应该。如果到分支生命周期结
>>>> 束了的时候再merge，就需要一种标记方法，标记出来哪100个应该合并到主分
>>>> 支。提交时立即merge的作用仅仅是一个“标记”，不然日后忘了 4043应该是合
>>>> 到主分支上，4044不应该。实际上尽管b是经常更新的，但是主干每几个月接受
>>>> 一次merge都是可以的，因为实际上主干近于半年才发行一次。而b常常需要每
>>>> 一两周都更新到作业系统一次。
>>>>
>>>>
>>>> _______________________________________________
>>>> zeuux-universe mailing list
>>>> zeuux-universe at zeuux.org zeuux-universe at zeuux.org>
>>>> http://www.zeuux.org/mailman/listinfo/zeuux-universe
>>>>
>>>> ZEUUX Project - Free Software, Free Society!
>>>> http://www.zeuux.org
>>>>         
>> -- 
>> Real Softservice
>>
>> Huateng Tower, Unit 1788
>> Jia 302 3rd area of Jinsong, Chao Yang
>>
>> Tel: +86 (10) 8773 0650 ext 603
>> Mobile: 159 1111 7382
>> http://www.realss.com
>>
>> _______________________________________________
>> zeuux-universe mailing list
>> zeuux-universe at zeuux.org
>> http://www.zeuux.org/mailman/listinfo/zeuux-universe
>>
>> ZEUUX Project - Free Software, Free Society!
>> http://www.zeuux.org
>>     


-- 
Real Softservice

Huateng Tower, Unit 1788
Jia 302 3rd area of Jinsong, Chao Yang

Tel: +86 (10) 8773 0650 ext 603
Mobile: 159 1111 7382
http://www.realss.com

我想，你这个问题设计到SOA开发的问题。面向不同的客 
户需要做不同的定制。
在 2008-6-7，下午8:59， Zhang Weiwu 写道：

> Fwolf wrote:
>> 能否考虑用配置文件分开？这样就不用开分支了。
>>
> 将其集中成为可配置选项是我们一开始采用的思路， 
> 但是发现增加了代码维护量，
> 原因是很多选项是除了B公司以外，没有人会选中采用 
> 的，加上为此在选项模块增
> 加了钩子，钩子多了也不易管理，C公司常常觉得系统 
> 无法控制，主要程序员也和
> 我来了一次不怎么愉快的谈话，认为可选东西太多 
> 了。比如为啤酒节准备的那个功
> 能，显然除了B公司其它人不会再用了，增加一个啤酒 
> 节选项很怪的。
>> On Sat, Jun 07, 2008 at 07:08:35PM +0800, Zhang Weiwu wrote:
>>
>>> Sutra Zhou wrote:
>>>
>>>> 为什么会有20个修改不应该merge到主干呢？
>>>> 是因为已经merge过了，还是这个修改不需要了？
>>>> 如果这个修改不需要了，是需要人工判断一下，如 
>>>> 果已经merge过了，再次merge
>>>> 的时候根本看不到它了。
>>>>
>>> 举一个例子：B公司内部使用Lotus Notes 6.x，不支持 
>>> UTF-8，所以无法阅读收到
>>> 的系统通知信。但是所有其它的客户都没有这种情 
>>> 况（有的是用新版的Lotus
>>> Notes），而B公司不打算花钱升级。所以b分支上事先 
>>> 将电子邮件转为HTML格式，
>>> 使用entities表示特殊字符。这变化是逆潮流而动，不 
>>> 应该 merge到主干。这种事
>>> 其实挻多的，我还可以找出好些例子呢。
>>>
>>>> 在 2008-6-7，下午7:03， Zhang Weiwu 写道：
>>>>
>>>>
>>>>> Zhang Weiwu wrote:
>>>>>
>>>>>> Sutra Zhou wrote:
>>>>>>
>>>>>>
>>>>>>> 没必要每次都merge，如果每次提交到分支的代码 
>>>>>>> 都需要merge到主干，那我觉得
>>>>>>> 项目的管理是有问题的。
>>>>>>>
>>>>>>> 我觉得在分支生命周期结束了的时候再merge不 
>>>>>>> 迟，主干上的代码一般都比较激
>>>>>>> 进地在开发新功能，如没有必要，压根没有必要 
>>>>>>> 合并上来。
>>>>>>>
>>>>>>>
>>>>>>>
>>>>> 报歉，我误解了你的问题。我以为你是说为何将生 
>>>>> 命周期安排得这样短。
>>>>>
>>>>> 在分支生命周期结束了的时候再merge的问题是，在 
>>>>> 分支生命周期里一共有120
>>>>> 个修改，其中100个应该合并到主分支上，20个不应 
>>>>> 该。如果到分支生命周期结
>>>>> 束了的时候再merge，就需要一种标记方法，标记出 
>>>>> 来哪100个应该合并到主分
>>>>> 支。提交时立即merge的作用仅仅是一个“标记”， 
>>>>> 不然日后忘了 4043应该是合
>>>>> 到主分支上，4044不应该。实际上尽管b是经常更新 
>>>>> 的，但是主干每几个月接受
>>>>> 一次merge都是可以的，因为实际上主干近于半年才 
>>>>> 发行一次。而b常常需要每
>>>>> 一两周都更新到作业系统一次。
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> zeuux-universe mailing list
>>>>> zeuux-universe在zeuux.org zeuux-universe在zeuux.org>
>>>>> http://www.zeuux.org/mailman/listinfo/zeuux-universe
>>>>>
>>>>> ZEUUX Project - Free Software, Free Society!
>>>>> http://www.zeuux.org
>>>>>
>>> -- 
>>> Real Softservice
>>>
>>> Huateng Tower, Unit 1788
>>> Jia 302 3rd area of Jinsong, Chao Yang
>>>
>>> Tel: +86 (10) 8773 0650 ext 603
>>> Mobile: 159 1111 7382
>>> http://www.realss.com
>>>
>>> _______________________________________________
>>> zeuux-universe mailing list
>>> zeuux-universe在zeuux.org
>>> http://www.zeuux.org/mailman/listinfo/zeuux-universe
>>>
>>> ZEUUX Project - Free Software, Free Society!
>>> http://www.zeuux.org
>>>
>
>
> -- 
> Real Softservice
>
> Huateng Tower, Unit 1788
> Jia 302 3rd area of Jinsong, Chao Yang
>
> Tel: +86 (10) 8773 0650 ext 603
> Mobile: 159 1111 7382
> http://www.realss.com
>
> _______________________________________________
> zeuux-universe mailing list
> zeuux-universe在zeuux.org
> http://www.zeuux.org/mailman/listinfo/zeuux-universe
>
> ZEUUX Project - Free Software, Free Society!
> http://www.zeuux.org

-------------- 下一部分 --------------
一个HTML附件被移除...
URL: http://www.zeuux.org/pipermail/zeuux-universe/attachments/20080607/8344ea48/attachment-0001.html 

我说的并非用户可见的选项，而是隐藏的系统级选项，这样用户就不会烦了。
在程序中，B公司的特殊定制可以采用再派生类的做法，这样通用的做法
可以很容易得移植到父类当中，当然这只是一个思路，还要视具体情况来定。

参考一下很多软件发布的时候，都有商业版、精简版。。。之类
他们是如何管理和发布的呢？

On Sat, Jun 07, 2008 at 10:48:45PM +0900, Sutra Zhou wrote:
> 我想，你这个问题设计到SOA开发的问题。面向不同的客户需要做不同的定制。
> 在 2008-6-7，下午8:59， Zhang Weiwu 写道：
> 
> 
>     Fwolf wrote:
> 
>         能否考虑用配置文件分开？这样就不用开分支了。
> 
> 
> 
>     将其集中成为可配置选项是我们一开始采用的思路，但是发现增加了代码维护量，
>     原因是很多选项是除了B公司以外，没有人会选中采用的，加上为此在选项模块增
>     加了钩子，钩子多了也不易管理，C公司常常觉得系统无法控制，主要程序员也和
>     我来了一次不怎么愉快的谈话，认为可选东西太多了。比如为啤酒节准备的那个功
>     能，显然除了B公司其它人不会再用了，增加一个啤酒节选项很怪的。
> 
>         On Sat, Jun 07, 2008 at 07:08:35PM +0800, Zhang Weiwu wrote:
> 
> 
> 
>             Sutra Zhou wrote:
> 
> 
> 
>                 为什么会有20个修改不应该merge到主干呢？
> 
>                 是因为已经merge过了，还是这个修改不需要了？
> 
>                 如果这个修改不需要了，是需要人工判断一下，如果已经merge过了，再
>                 次merge
> 
>                 的时候根本看不到它了。
> 
> 
> 
>             举一个例子：B公司内部使用Lotus Notes 6.x，不支持UTF-8，所以无法阅读
>             收到
> 
>             的系统通知信。但是所有其它的客户都没有这种情况（有的是用新版的Lotus
> 
>             Notes），而B公司不打算花钱升级。所以b分支上事先将电子邮件转为HTML格
>             式，
> 
>             使用entities表示特殊字符。这变化是逆潮流而动，不应该 merge到主干。
>             这种事
> 
>             其实挻多的，我还可以找出好些例子呢。
> 
> 
> 
>                 在 2008-6-7，下午7:03， Zhang Weiwu 写道：
> 
> 
> 
> 
> 
>                     Zhang Weiwu wrote:
> 
> 
> 
>                         Sutra Zhou wrote:
> 
> 
> 
> 
> 
>                             没必要每次都merge，如果每次提交到分支的代码都需要
>                             merge到主干，那我觉得
> 
>                             项目的管理是有问题的。
> 
> 
> 
>                             我觉得在分支生命周期结束了的时候再merge不迟，主干上
>                             的代码一般都比较激
> 
>                             进地在开发新功能，如没有必要，压根没有必要合并上来
>                             。
> 
> 
> 
> 
> 
> 
> 
>                     报歉，我误解了你的问题。我以为你是说为何将生命周期安排得这
>                     样短。
> 
> 
> 
>                     在分支生命周期结束了的时候再merge的问题是，在分支生命周期里
>                     一共有120
> 
>                     个修改，其中100个应该合并到主分支上，20个不应该。如果到分支
>                     生命周期结
> 
>                     束了的时候再merge，就需要一种标记方法，标记出来哪100个应该
>                     合并到主分
> 
>                     支。提交时立即merge的作用仅仅是一个“标记”，不然日后忘了
>                     4043应该是合
> 
>                     到主分支上，4044不应该。实际上尽管b是经常更新的，但是主干每
>                     几个月接受
> 
>                     一次merge都是可以的，因为实际上主干近于半年才发行一次。而b
>                     常常需要每
> 
>                     一两周都更新到作业系统一次。
> 
> 
> 
> 
> 
>                     _______________________________________________
> 
>                     zeuux-universe mailing list
> 
>                     zeuux-universe at zeuux.org zeuux-universe at zeuux.org>
> 
>                     http://www.zeuux.org/mailman/listinfo/zeuux-universe
> 
> 
> 
>                     ZEUUX Project - Free Software, Free Society!
> 
>                     http://www.zeuux.org
> 
> 
> 
>             --
> 
>             Real Softservice
> 
> 
> 
>             Huateng Tower, Unit 1788
> 
>             Jia 302 3rd area of Jinsong, Chao Yang
> 
> 
> 
>             Tel: +86 (10) 8773 0650 ext 603
> 
>             Mobile: 159 1111 7382
> 
>             http://www.realss.com
> 
> 
> 
>             _______________________________________________
> 
>             zeuux-universe mailing list
> 
>             zeuux-universe at zeuux.org
> 
>             http://www.zeuux.org/mailman/listinfo/zeuux-universe
> 
> 
> 
>             ZEUUX Project - Free Software, Free Society!
> 
>             http://www.zeuux.org
> 
> 
> 
> 
> 
>     --
>     Real Softservice
> 
>     Huateng Tower, Unit 1788
>     Jia 302 3rd area of Jinsong, Chao Yang
> 
>     Tel: +86 (10) 8773 0650 ext 603
>     Mobile: 159 1111 7382
>     http://www.realss.com
> 
>     _______________________________________________
>     zeuux-universe mailing list
>     zeuux-universe at zeuux.org
>     http://www.zeuux.org/mailman/listinfo/zeuux-universe
> 
>     ZEUUX Project - Free Software, Free Society!
>     http://www.zeuux.org
> 
> 

> _______________________________________________
> zeuux-universe mailing list
> zeuux-universe at zeuux.org
> http://www.zeuux.org/mailman/listinfo/zeuux-universe
> 
> ZEUUX Project - Free Software, Free Society!
> http://www.zeuux.org

-- 
http://www.fwolf.com/
欧洲人搞理论，美国人搞创新，日本人把它做精，韩国人把它做得赚钱，中国人把它做到没钱赚。
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://www.zeuux.org/pipermail/zeuux-universe/attachments/20080608/0b70b10e/attachment.bin 

Fwolf wrote:
> 我说的并非用户可见的选项，而是隐藏的系统级选项，这样用户就不会烦了。
> 在程序中，B公司的特殊定制可以采用再派生类的做法，这样通用的做法
> 可以很容易得移植到父类当中，当然这只是一个思路，还要视具体情况来定。
>   
无论采用什么方法，只要不是使用版本控制的办法，就得回答一些问题：为什么发
行的软件产品有那么多用户不到的功能和修改？尤其是软件开源的情况下，其它人
可以读的到代码为什么有这样的用户定制特色？如果开源软件不是本公司发行，还
有另一个问题，就是代码上游的管理人为什么会许可这样的定制选项进入上游？以
Linux Kernel为例，Linus看到系统选项中“支持啤酒节活动”这一个选项，可能会
觉得B的啤酒节活动干我什么事，也就不会让这个设置进入上游，这样这个问题仍
得回到版本控制层面上管理。

采用良好的OOP结构和设计模式的重要用意，是使得定制的修改由“困难”变为“可
能”，而并不是使之存在在主干代码中。
> 参考一下很多软件发布的时候，都有商业版、精简版。。。之类
> 他们是如何管理和发布的呢？
>   
“商业版、精简版”面临的问题其实和我上文说的问题还是有区别的。发行“商业版、精简版”
倒是比较好解决，因为这是比较确定应该成为build option或系统设置的东西。又以上面Linus为例，他可能不会让“支持啤酒节”选项进入上游，但是看到“精简版”选项，那就高兴地接受到上游了。

On Sun, Jun 08, 2008 at 11:49:30AM +0800, Zhang Weiwu wrote:
> Fwolf wrote:
> > 我说的并非用户可见的选项，而是隐藏的系统级选项，这样用户就不会烦了。
> > 在程序中，B公司的特殊定制可以采用再派生类的做法，这样通用的做法
> > 可以很容易得移植到父类当中，当然这只是一个思路，还要视具体情况来定。
> >   
> 无论采用什么方法，只要不是使用版本控制的办法，就得回答一些问题：为什么发
> 行的软件产品有那么多用户不到的功能和修改？尤其是软件开源的情况下，其它人
> 可以读的到代码为什么有这样的用户定制特色？如果开源软件不是本公司发行，还
> 有另一个问题，就是代码上游的管理人为什么会许可这样的定制选项进入上游？以
> Linux Kernel为例，Linus看到系统选项中“支持啤酒节活动”这一个选项，可能会
> 觉得B的啤酒节活动干我什么事，也就不会让这个设置进入上游，这样这个问题仍
> 得回到版本控制层面上管理。
> 
> 采用良好的OOP结构和设计模式的重要用意，是使得定制的修改由“困难”变为“可
> 能”，而并不是使之存在在主干代码中。
> > 参考一下很多软件发布的时候，都有商业版、精简版。。。之类
> > 他们是如何管理和发布的呢？
> >   
> “商业版、精简版”面临的问题其实和我上文说的问题还是有区别的。发行“商业版、精简版”
> 倒是比较好解决，因为这是比较确定应该成为build option或系统设置的东西。又以上面Linus为例，他可能不会让“支持啤酒节”选项进入上游，但是看到“精简版”选项，那就高兴地接受到上游了。
> 
> 

程序版本或分支多了的确是难于管理，嗯，如果采用hack或者plugin的机制来实现呢？
上游增加plugin机制应该是可以接受的，
下游分支只需包含plugin部分即可。
我知道，说是这么说，实现起来还是有难度的。

-- 
http://www.fwolf.com/
It usually takes more than three weeks to prepare a good impromptu speech.
		-- Mark Twain
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://www.zeuux.org/pipermail/zeuux-universe/attachments/20080608/5b628894/attachment.bin 

2008/6/4 夏清然 Xia Qingran <qingran.xia在gmail.com>:
> FreeBSD稳定运行了10多年的CVS代码库开始转向SVN了。
>
> 咱们邮件列表中有很多朋友在商业公司工作，能否说说各自的Version Control用的什么？
>
> 新浪目前是以SVN为主。
>
小外包公司，正在从CVS向SVN转化中。挺喜欢SVN的，兼职了半年的CM，基本把SVN都摸熟了，感觉很强大。

GIT没有详细摸过，感觉不是很顺手，最近在一个用Clearcae的组解BUG，对CC也不是很喜欢，有点中毒了。

-- 
Best Regards,
Tang, Jiyu

2008/6/5 夏武 <xia.wu.cn在gmail.com>:
> 版本控制工具挺重要，不过，我想最重要的是进行版本控制的规章制度，大家能不能谈谈各公司都是制度都是怎样的？（据说某些公司还罚款、体罚，呵呵）
>
>
> 夏武
>
听说过一个policy，一个组10个人，加一个玩具，谁拿着玩具，谁才能commit code，不然就得等着。


-- 
Best Regards,
Tang, Jiyu

ÄÇÕâ¸öÍæ¾ß£¨ÁîÅÆ£©ÊÇÈçºÎ»ñµÃµÄÄØ£¿ºÇºÇ¡£
ÔÚ 2008-6-11£¬ÏÂÎç7:10£¬ A.TNG дµÀ£º

> 2008/6/5 ÏÄÎä <xia.wu.cn在gmail.com>:
>> °æ±¾¿ØÖƹ¤¾ßͦÖØÒª£¬²»¹ý£¬ÎÒÏë×îÖØÒª 
>> µÄÊǽøÐа汾¿ØÖƵĹæÕÂÖƶȣ¬´ó¼ÒÄܲ» 
>> ÄÜ̸̸¸÷¹«Ë¾¶¼ÊÇÖƶȶ¼ÊÇÔõÑùµÄ£¿£¨¾Ý˵ijЩ¹«Ë¾»¹·£¿î¡¢Ìå·££¬ºÇºÇ£©
>>
>>
>> ÏÄÎä
>>
> Ìý˵¹ýÒ»¸öpolicy£¬Ò»¸ö×é10¸öÈË£¬¼ÓÒ»¸ö 
> Íæ¾ß£¬Ë­ÄÃ×ÅÍæ¾ß£¬Ë­²ÅÄÜcommit code£¬²»È»¾ÍµÃµÈ×Å¡£
>
>
> -- 
> Best Regards,
> Tang, Jiyu
> _______________________________________________
> zeuux-universe mailing list
> zeuux-universe在zeuux.org
> http://www.zeuux.org/mailman/listinfo/zeuux-universe
>
> ZEUUX Project - Free Software, Free Society!
> http://www.zeuux.org

-------------- 下一部分 --------------
Ò»¸öHTML¸½¼þ±»ÒƳý...
URL: http://www.zeuux.org/pipermail/zeuux-universe/attachments/20080611/0b3b851e/attachment-0001.html 

2008/6/11 Sutra Zhou <zhoushuqun在gmail.com>:
> 那这个玩具（令牌）是如何获得的呢？呵呵。

基本上是，谁需要commit code，谁去获得，倒是没听说有具体的policy。

> 在 2008-6-11，下午7:10， A.TNG 写道：
>
> 2008/6/5 夏武 <xia.wu.cn在gmail.com>:
>
> 版本控制工具挺重要，不过，我想最重要的是进行版本控制的规章制度，大家能不能谈谈各公司都是制度都是怎样的？（据说某些公司还罚款、体罚，呵呵）
>
>
> 夏武
>
> 听说过一个policy，一个组10个人，加一个玩具，谁拿着玩具，谁才能commit code，不然就得等着。




-- 
Best Regards,
Tang, Jiyu