PUB:20141108 When hackers grow old

@Stevearzh
This commit is contained in:
wxy 2015-01-12 15:57:42 +08:00
parent be147eb7fe
commit 25d2d99051

View File

@ -1,4 +1,4 @@
黑客年暮 ESR黑客年暮
================================================================================ ================================================================================
近来我一直在与某资深开源开发团队中的多个成员缠斗,尽管密切关注我的人们会在读完本文后猜到是哪个组织,但我不会在这里说出这个组织的名字。 近来我一直在与某资深开源开发团队中的多个成员缠斗,尽管密切关注我的人们会在读完本文后猜到是哪个组织,但我不会在这里说出这个组织的名字。
@ -10,15 +10,15 @@
为什么是我?因为年轻人在我的同龄人中很难有什么说服力。如果有人想让那帮老头改变主意,首先他得是自己同龄人中具有较高思想觉悟的佼佼者。即便如此,在与习惯做斗争的过程中,我也比看起来花费了更多的时间。 为什么是我?因为年轻人在我的同龄人中很难有什么说服力。如果有人想让那帮老头改变主意,首先他得是自己同龄人中具有较高思想觉悟的佼佼者。即便如此,在与习惯做斗争的过程中,我也比看起来花费了更多的时间。
年轻人犯下无知的错误是可以被原谅的。他们还年轻。年轻意味着缺乏经验,缺乏经验通常会导致片面的判断。我很难原谅那些经历了足够多本该有经验的人,却被<em>长期的固化思维</em>蒙蔽,无法发觉近在咫尺的东西。 年轻人犯下无知的错误是可以被原谅的。他们还年轻。年轻意味着缺乏经验,缺乏经验通常会导致片面的判断。我很难原谅那些经历了足够多本该有经验的人,却被*长期的固化思维*蒙蔽,无法发觉近在咫尺的东西。
(补充一下:我真的不是保守党拥护者。那些和我争论政治的,无论保守党还是非保守党都没有注意到这点,我觉得这颇有点嘲讽的意味。) (补充一下:我真的不是保守党拥护者。那些和我争论政治的,无论保守党还是非保守党都没有注意到这点,我觉得这颇有点嘲讽的意味。)
那么,现在我们来讨论下 GNU 更新日志文件ChangeLog这件事。在 1985 年的时候,这是一个不错的主意,甚至可以说是必须的。当时的想法是用单独的更新日志条目来记录多个相关文件的变更情况。用这种方式来对那些存在版本缺失或者非常原始的版本进行版本控制确实不错。当时我也在场,所以我知道这些。 那么,现在我们来讨论下 GNU 更新日志文件ChangeLog这件事。在 1985 年的时候,这是一个不错的主意,甚至可以说是必须的。当时的想法是用单独的更新日志条目来记录多个相关文件的变更情况。用这种方式来对那些存在版本缺失或者非常原始的版本进行版本控制确实不错。当时我也*在场*,所以我知道这些。
不过即使到了 1995 年,甚至 21 世纪早期许多版本控制系统仍然没有太大改进。也就是说这些版本控制系统并非对批量文件的变化进行分组再保存到一条记录上而是对每个变化的文件分别进行记录并保存到不同的地方。CVS当时被广泛使用的版本控制系统仅仅是模拟日志变更 —— 并且在这方面表现得很糟糕,导致大多数人不再依赖这个功能。即便如此,更新日志文件的出现依然是必要的。 不过即使到了 1995 年,甚至 21 世纪早期许多版本控制系统仍然没有太大改进。也就是说这些版本控制系统并非对批量文件的变化进行分组再保存到一条记录上而是对每个变化的文件分别进行记录并保存到不同的地方。CVS当时被广泛使用的版本控制系统仅仅是模拟日志变更 —— 并且在这方面表现得很糟糕,导致大多数人不再依赖这个功能。即便如此,更新日志文件的出现依然是必要的。
但随后,版本控制系统 Subversion 于 2003 年发布 beta 版,并于 2004 年发布 1.0 正式版Subversion 真正实现了更新日志记录功能得到了人们的广泛认可。它与一年后兴起的分布式版本控制系统Distributed Version Control SystemDVCS共同引发了主流世界的激烈争论。因为如果你在项目上同时使用了分式版本控制与更新日志文件记录的功能,它们将会因为争夺相同元数据的控制权而产生不可预料的冲突。 但随后,版本控制系统 Subversion 于 2003 年发布 beta 版,并于 2004 年发布 1.0 正式版Subversion 真正实现了更新日志记录功能得到了人们的广泛认可。它与一年后兴起的分布式版本控制系统Distributed Version Control SystemDVCS共同引发了主流世界的激烈争论。因为如果你在项目上同时使用了分式版本控制与更新日志文件记录的功能,它们将会因为争夺相同元数据的控制权而产生不可预料的冲突。
有几种不同的方法可以折衷解决这个问题。一种是继续将更新日志作为代码变更的授权记录。这样一来,你基本上只能得到简陋的、形式上的提交评论数据。 有几种不同的方法可以折衷解决这个问题。一种是继续将更新日志作为代码变更的授权记录。这样一来,你基本上只能得到简陋的、形式上的提交评论数据。
@ -26,9 +26,9 @@
(现在,试想有这样一个项目,同样本着把项目做得最好的想法,但两拨人却做出了完全不同的选择。因此你必须同时阅读更新日志和评论日志以了解到底发生了什么。最好在矛盾激化前把问题解决.... (现在,试想有这样一个项目,同样本着把项目做得最好的想法,但两拨人却做出了完全不同的选择。因此你必须同时阅读更新日志和评论日志以了解到底发生了什么。最好在矛盾激化前把问题解决....
第三种办法是尝试同时使用以上两种方法 —— 在更新日志条目中以稍微变化后的的格式复制一份评论数据将其作为评论提交的一部分。这会导致各种你意想不到的问题最具代表性的就是它不符合“真理的单点性single point of truth”原理只要其中有拷贝文件损坏或者日志文件条目被修改这就不再是同步时数据匹配的问题它将导致在其后参与进来的人试图搞清人们是怎么想的时候变得非常困惑。 第三种办法是尝试同时使用以上两种方法 —— 在更新日志条目中以稍微变化后的的格式复制一份评论数据将其作为评论提交的一部分。这会导致各种你意想不到的问题最具代表性的就是它不符合“真理的单点性single point of truth”原理只要其中有拷贝文件损坏或者日志文件条目被修改这就不再是同步时数据匹配的问题它将导致在其后参与进来的人试图搞清人们是怎么想的时候变得非常困惑。LCTT 译注:《[程序员修炼之道][1]》The Pragmatic Programmer任何一个知识点在系统内都应当有一个唯一、明确、权威的表述。根据Brian Kernighan的建议把这个原则称为“真理的单点性Single Point of Truth”或者SPOT原则。
或者,正如这个<em>我就不说出具体名字的特定项目</em>所做的,它的高层开发人员在电子邮件中最近声明说,提交可以包含多个更新日志条目,并且提交的元数据与更新日志是无关的。这导致我们直到现在还得不断进行记录。 或者,正如这个*我就不说出具体名字的特定项目*所做的,它的高层开发人员在电子邮件中最近声明说,提交可以包含多个更新日志条目,并且提交的元数据与更新日志是无关的。这导致我们直到现在还得不断进行记录。
当时我读到邮件的时候都要吐了。什么样的傻瓜才会意识不到这是自找麻烦 —— 事实上,在 DVCS 中针对可靠的提交日志有很好的浏览工具,围绕更新日志文件的整个定制措施只会成为负担和拖累。 当时我读到邮件的时候都要吐了。什么样的傻瓜才会意识不到这是自找麻烦 —— 事实上,在 DVCS 中针对可靠的提交日志有很好的浏览工具,围绕更新日志文件的整个定制措施只会成为负担和拖累。
@ -63,3 +63,4 @@ via: http://esr.ibiblio.org/?p=6485
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创翻译,[Linux中国](http://linux.cn/) 荣誉推出 本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创翻译,[Linux中国](http://linux.cn/) 荣誉推出
[a]:http://esr.ibiblio.org/?author=2 [a]:http://esr.ibiblio.org/?author=2
[1]:http://book.51cto.com/art/200809/88490.htm