不知道 mod by *** on 20050814 这样的注释有什么意思？

leeon868

原帖由 zhkl125 于 2007-8-8 11:55 发表
人微言轻啊

我不知道这句话到底的意义是什么。

我以前所在的一个大公司。（恕不便相告）

在做培训的时候，老师就说，人多并不意味着道理就是对的。

如果有自己的观点，就要据理力争，要真正做到摆事实讲道理。在合适的环境下解释清楚。

这样的据理力争并不一定是坏处，即便不能被采用，也有一个自己研究的过程。

自己在整理资料试图说服管理者的时候，其实自己也在做深入地研究，就是自己职业生涯的一笔财富。或许换个公司就被采纳了呢？

我想，一个企业的管理者，不会放过任何一个能够降低成本的东西。

还手工编译你的项目吗？没有Automatic的概念啊？没有的话，请重新审视自己是否确定以及一定在用Unix/Unix-like系统。是否符合unix哲学。

现在大项目都引入Builder这个概念了，我以前就介绍公司在windows下使用FinalBuider，非常容易使用，企业级的。
Linux下，以前是写makefile，现在用工具，比如jam，boost-build，还有其他的东西。都很方便。可谓一劳永逸。

从代码到安装包，到刻录光盘，都是自动化的Builder。

而自动化编译的一个核心概念，就是版本控制。

我要一个2007-08-01的版本的安装光盘，没问题。脚本修改参数，自动check out代码，然后放入光盘，出来安装程序，找客户去了。

大型项目的测试，也是自动化脚本，连续测试几个版本，都要涉及到版本控制。

把不用的代码注释掉，或者把修改的地方用类似//modified by XXX这样的代码标注。你能知道以前的代码就一定是不好的？错的？不能用的？

是软件各种自动化最大阻力。

请看《Unix编程艺术》

Unix哲学：小工具来解决大项目的问题。

[ 本帖最后由 leeon868 于 2007-8-8 12:50 编辑 ]

flw

原帖由 leeon868 于 2007-8-8 12:46 发表

我不知道这句话到底的意义是什么。

我以前所在的一个大公司。（恕不便相告）

在做培训的时候，老师就说，人多并不意味着道理就是对的。

如果有自己的观点，就要据理力争，要真正做到摆事实讲道理。在合适的环境下解释清楚。

这样的据理力争并不一定是坏处，即便不能被采用，也有一个自己研究的过程。

自己在整理资料试图说服管理者的时候，其实自己也在做深入地研究，就是自己职业生涯的一笔财富。或许换个公司就被采纳了呢？

我想，一个企业的管理者，不会放过任何一个能够降低成本的东西。

还手工编译你的项目吗？没有Automatic的概念啊？没有的话，请重新审视自己是否确定以及一定在用Unix/Unix-like系统。是否符合unix哲学。

现在大项目都引入Builder这个概念了，我以前就介绍公司在windows下使用FinalBuider，非常容易使用，企业级的。
Linux下，以前是写makefile，现在用工具，比如jam，boost-build，还有其他的东西。都很方便。可谓一劳永逸。

从代码到安装包，到刻录光盘，都是自动化的Builder。

而自动化编译的一个核心概念，就是版本控制。

我要一个2007-08-01的版本的安装光盘，没问题。脚本修改参数，自动check out代码，然后放入光盘，出来安装程序，找客户去了。

大型项目的测试，也是自动化脚本，连续测试几个版本，都要涉及到版本控制。

把不用的代码注释掉，或者把修改的地方用类似//modified by XXX这样的代码标注。你能知道以前的代码就一定是不好的？错的？不能用的？

是软件各种自动化最大阻力。

请看《Unix编程艺术》

Unix哲学：小工具来解决大项目的问题。

真是知音啊。
我也是前几年才明白这个道理的。

> 我要一个2007-08-01的版本的安装光盘，没问题。脚本修改参数，自动check out代码，然后放入光盘，出来安装程序，找客户去了。
采用 mod by **** 方法的朋友们，恐怕只能靠备份了吧？
所以我才猜测前面那位朋友是不是有很多 foo-20070801.tgz 或者 foo-for-cctv.tgz 这样的备份文件了。
如果没有备份，难不成一个一个找 mod by ***，然后把 2007-08-01 之后的修改都还原，然后就变成 2007-08-01 那天的了？

leeon868

企业级的，

release版本交给销售部门去应用。
unstable版本还在程序员手里开发。
beta版本已经提交给二楼测试部门去做测试了。

程序员需要整理三份代码？版本控制下，三个部门只需要三条指令而已。而且互不干涉。

这就是我前面所提到的“趋势“。

其实不管企业级，还是个人应用级，都应该引入这些概念。

[ 本帖最后由 leeon868 于 2007-8-8 13:03 编辑 ]

yulc

原帖由 leeon868 于 2007-8-8 13:01 发表
企业级的，

release版本交给销售部门去应用。
unstable版本还在程序员手里开发。
beta版本已经提交给二楼测试部门去做测试了。

程序员需要整理三份代码？版本控制下，三个部门只需要三条指令而已。而且 ...

嗯,理论是这样的...

leeon868

理论上这样，实践上至少也要做到unstable版本和release版本的区分。

zicfy

小弟不才，斗胆向大家推荐一个开源项目: Trac, 主页是: http://trac.edgewall.org/
他是一个项目管理系统，包括CM系统（基于SVN)

关于CM这一块，有兴趣的可以打开主页，然后点上方导航栏的"timeline"
然后再右上角的过滤栏里，只选中"Repository checkins"，点"Update"

近期代码改变就一览无余，包括revision log、日期、修改人：


随便点一个进去，可以看到本次代码改动的detail信息：


这样，比直接用svn更直观一点，当然安装这个系统要复杂一些。
版本管理，在代码这一块，目的是方便代码改变的跟踪和回溯以及多人协同编码。
而代码和系统的可维护性还是要靠代码注释和文档。

flw

支持 96 楼！
非常好。

emacsnw

这个看上去不错，不过p4就有类似的功能。

原帖由 zicfy 于 2007-8-7 22:13 发表
小弟不才，斗胆向大家推荐一个开源项目: Trac, 主页是: http://trac.edgewall.org/
他是一个项目管理系统，包括CM系统（基于SVN)

关于CM这一块，有兴趣的可以打开主页，然后点上方导航栏的"timeline"
然后 ...

leeon868

就学习来说，参与才是最重要的。为项目哪怕写一行代码也是宝贵的经验。

leeon868

原帖由 快乐的土豆 于 2007-8-8 14:31 发表
不知道为什么几位在大公司工作的牛人就一定认定这个 mod by xxxx 只能是做版本控制用的呢？

反问一句：mod by xxxx 就不是做版本控制用的呢？

一旦修改，就会出现版本。概念先搞清楚。

1.0.1

2.2.2

这些都是修改得来的。

既然写了modified by XXXXXX其实就是说明，我修改了这个地方，产生了一个新版本的代码。

除了产生新版本，那写这个有什么用？

而且LZ不就是在说这个的意思吗？