开发记事本

上一次写博客竟然已经是2006年了，时间真快，或者说，我偷了好长时间的懒。

这两年工作和生活都有所进步，希望以后的路都能够顺顺利利地走下去。

两年来的流水帐：
2006年10月10日：离开从2000年6月5日开始工作了6年多的原公司，在家休息了三个月；
2007年1月11日：进入现在的公司，被外派到微软作为Vendor工作；
2007年5月23日：奔三升级奔四；
2007年9月到12月：去微软总部工作3个月；
2008年5月6日：签订购房合同，成为房奴；

前几天在5460上看到同学们在嚷嚷毕业十周年的聚会，时间真的好快啊，转眼就十年了。

问题的产生：
对于采用Copy-Modified-Merge方式的版本控制系统，冲突的管理和解决是非常重要的。
目前公司的一个项目由于系统的版本升级，系统的源代码在开发过程中有大量的文件重命名操作，原有的CVS不支持文件重命名，每次都需要删除原有文件，再重新导入新的文件，导致文件更改历史丢失；为了解决这个问题，我们把版本控制工具从CVS改成了Subversion，客户端从TortoiseCVS改为了TortoiseSVN；由于TortoiseCVS和TortoiseSVN的使用极为相似，因此转移后大家在使用上并没有遇到什么问题——除了对文件冲突的解决方式；

问题的详细分析：
在文件的合并发生冲突时，冲突文件主要有以下几个版本：
Base：自己的工作复本中该文件的原始版本
Mine：自己的工作文件
Theirs：版本库中的最新文件
Merged：在TortoiseSVN中自动合并后的文件，在该文件中，用如下方式标识了文件中发生冲突的部分（这种方式似乎是Unix世界的通用方式？）：
<<<<<<< filename
    your changes
=======
    code merged from repository
>>>>>>> revision

在 TortoiseCVS 中，对冲突文件的合并是用Mine和Theirs进行比较进行的，合并后的文件即作为工作复本中冲突已解决的新文件；而在TortoiseSVN中，对于冲突的文件（比如ConflictFile.txt），会自动生成以下几个文件：

ConflictFile.txt.mine（自己的工作复本Mine）
ConflictFile.txt.rBaseRevision（原始版本Base）
ConflictFile.txt.rNewRevision（版本库中的新版本Theirs）
ConflictFile.txt（合并后的文件Merged）

TortoiseSVN 的冲突解决需要对以上文件进行比较合并，最终将所有的修改都合并到Merged版本中，然后将冲突设置为已解决；但是由于工作复本、版本库的新版本以及合并的目标分别存储在三个文件中，因此TortoiseSVN的冲突解决就需要使用支持三向比较（3-Ways）的比较/合并工具，比如TortoiseSVN内置的TortoiseMerge（免费），或者Araxis Merge（收费）；原来我们在TortoiseCVS中使用的Beyond Compare就无法使用了，因为BC只支持对两个文件进行比较，在TortoiseSVN中使用Beyond Compare作为合并工具的话，就还需要手工作很多工作——大家就是对这一点非常不适应。

问题解决方案：
1.编写如下的批处理文件（注意将Beyond Comare的路径改为实际的路径）：
"D:\Applications\DevTools\BeyondCompare2\BC2.exe" %1 %2
Del %3
Del %4
Del %2
Copy %1 %3
Del %1

2.在TortoiseSVN的Setting中选择合并工具（Merge Tool）页面，设置使用外部合并工具（External），在命令行中设置外部合并工具的命令行如下：
"D:\Applications\DevTools\TortoiseSVN\TSVNMerge.bat" %mine %theirs %merged %base

3.在使用TortoiseSVN编辑冲突文件时，系统会自动打开冲突文件的Mine版本和Theirs版本进行比较合并，用户将所有的修改合并到Mine版本中，当手工编辑冲突完成后，将自动用合并后的Mine版本替代Merged版本，并删除其他文件；这时使用TortoiseSVN的“标识为已解决”，即可进行提交。

此方法可以使用任何支持双向文件比较/合并的工具。

解决方案存在的问题：
这不是一个完美的解决方案，由于使用的是功能有限的批处理文件，因此存在以下问题：
1.无法判断用户是否进行了合并操作，如果没有进行合并操作，也会进行后面的删除和复制操作；
2.有时候会发生复制时提示Merged文件无法修改的情况，这可能是由于比较工具尚未完全退出造成的；

上面的问题可以通过自己编写程序解决，第一个问题通过用文件监视器监视Mine文件来判断是否进行了修改；第二个文件可以通过监视比较工具的进程进行判断。

很久没有去过CSDN了，今天上去发现首页上有一篇《开源GPL中触目惊心的学术腐败》，题目很是触目惊心，于是去看了看，结果发现是“太极语言”的创始人universee在对GNU/GPL大放厥词，开始还很是诧异，按universee的说法，他好歹也算是自己开发了一个新的语言，怎么会说出“没有GCC编译器，LINUX内核源代码稍微改动一下在MICROSOFT VC/MASM底下编译也是照样可以”这样的话，难道真的是天才现身，把Linux内核改动两行代码就能在VC下编译了？

看了《开源GPL中触目惊心的学术腐败二》以后，才发现原来universee对编译器和IDE都没有搞清楚，而且简单地把开源和GPL画上等号，不过还好知道GPL的核心内容是使用了遵循GPL协议的源代码，则必须遵循GPL协议开源。

而且universee一直在为麒麟开发组做着很没水平的辩护，看这一段：

我们的麒麟OS开发人员肯定很辛苦的，做为中国人应该对我们同胞的工作表示鼓励，而不是思维定势首先怀疑。我认为麒麟OS能用FREEBSD内核替换启动并不能证明麒麟OS就是抄袭的。反而充分证明了麒麟OS不是抄袭的，因为抄袭者必定心虚，必定至少做到内核替换则不能启动（这根本用不了几句话，很简单），否则这漏洞太大了吧，敢唱空城计的可不是一般的啊。那么目前保持内核兼容性的原因是什么呢？可能是为了把FreeBSD上许多软件都迅速移植过来，而不是再重新开发。

这种辩护让我觉得universee不是麒麟开发组的开发人员，就是麒麟聘的枪手；如果是前者，那么这样水平的开发人员很明显不可能做出什么高水平的系统，如果是后者，那么麒麟的运作水平实在太差了，找枪手也要找水平高一点的啊……

借用网友jiangtao9999的评论：“什么都不知道不是你的错，但出来丢人就是你的不对了。”

这种文章居然被放在CSDN首页上，嗯，我得说，我对CSDN是越来越看不懂，越来越失望了。

CSDN上还有另外一个活宝：Sinox的“汉澳操作系统”；大约从2003年起Sinox就以一种妄想狂的姿态在CSDN上宣传他的汉澳操作系统，时至今日仍然不改初衷，不时地出来喊两嗓子；不过从来没有见过CSDN对其有过什么处理措施。

这两位可以称作CSDN双雄，用梁启超的评价方法，一个是“狗放屁”，一个是“放屁狗”，就这点区别而已。

前段时间刚刚向大家推荐了DotNet下的开源图形控件The Netron Project，才不过半个月的时间，Netron项目就没有了，真是世事难料啊。

在CodeProject上（http://www.codeproject.com/script/profile/whos_who.asp?vt=arts&id=524590）Netron的作者Francois *Swa* Vanderseypen有一个简单的自我介绍，这篇自我介绍说明：Francois实实在在是一个天才：

Job: .Net architect in Belgium. Heterogeneous integrations, now more than ten years in the field. Time flies...During working hours I play with IBM Tivoli, SQL Server, mainframes, WebSphere MQ and everything in between. If you have a challenging job for me, drop me a note

Interests: as good as everything, but with a PhD in theoretical physics you can assume I spend a lot of time with mathematical ideas and complexity. Quantum gravity (Loops and knots) in my nostalgic moments. I tend to improvize a lot on my piano and thanks to the blogging phenomenon I write quite a lot of pseudo-philosophical essays.

天才可以写出一流的软件，但未必能够成功地推动一个开源项目，非常优秀的The Netron Project似乎名声不是很大。

Netron的最后版本2005年夏天发布的v2.2.2036；在2006-01-19作者发布新闻：预计将在七月份发布全新的3.0版本，功能也将比2.2强大更多；

然而我们可能永远都无法等到这个版本了。

在我向大家推荐Netron的时候，Netron的主页（http://netron.sourceforge.net）已经无法访问，所有的资料全部丢失，取而代之的是一首诗：

The truly creative mind in any field is no more than this:
A human creature born abnormally, inhumanly sensitive.
To him…
a touch is a blow,
a sound is a noise,
a misfortune is a tragedy,
a joy is an ecstasy,
a friend is a lover,
a lover is a god,
and failure is death.
Add to this cruelly delicate organism the overpowering necessity to create, create, create -
so that without the creating of music or poetry or books or buildings or something of meaning,
his very breath is cut off from him.
He must create, must pour out creation.
By some strange, unknown, inward urgency he is not really alive
unless he is creating.

(Pearl Buck)

这个时候很难知道发生了什么事情，大约2006-06-13左右，访问netron.sourceforge.net看到的是如下的内容：

Give me,
a job with free spacetime for working on diagramming stuff,
a fair allotment and good coffee,
no commercial worries, just faith in innovative ideas.
In return I can give you
the best .Net open source around,
creativity and passion unlimited,
an inspiring and erudite compeer,
impartial friendship, true commitment.

Let me,
be.

Until then; I am sorry.

看来作者对于工作和爱好的矛盾已经无法调和了（是谁说国外搞开源的程序员都是在衣食无忧的情况下搞开源的？），但是因此而删除网站内容的行为似乎不太应该，由于Netron项目一直缺乏很详尽的文档，Netron主页上的资料（主要是其中的一些教程）对于Netron的学习和使用是至关重要的，删除网站内容对于Netron的使用会造成非常大的困难。

随后，Netron在SourceForge（http://www.sourceforge.net/projects/netron）上的项目内容除了CVS仓库以外全部被删除，共同开发人员也已经被Francois删除，再去访问netron.sourceforge.net，则是如下内容：

While I beg you for your financial help,
you continue asking me my latest code
just to make sure
your business can continue.
My God,
the open source world is truly
a cruel place!

看来作者在寻求帮助的时候，得到的却都是索要源代码的请求，因此对开源已经失去了信心（the open source world is truly a cruel place!），做出了一个很极端的举动。

我想没办法责怪作者，毕竟自己为之付出了那么多的心血，却得不到积极响应是件很让人伤心的事情。

不过开源的好处在Netron目前的情况中得到了相当好的体现，Netron关闭后，用户only_me在SourceForge上注册了一个新的项目：Netron Reloaded；这个项目将延续Netron原有的代码和文档，并将作为Netron官方版本之外的一个分支继续开发下去。

这一期（2006年第7期）的《程序员》杂志在描述Ubuntu Linux的时候有一段话，用来说明Netron的当前状态很合适：“只要它仍然有益于社区，就会有人站在它倒下的地方，继续前行。开源的魅力正在于此。”

现在的情况：
Netron的主页（http://netron.sourceforge.net和http://www.netronproject.com）都指向了一个商业图形软件的订购页面；有人说是作者把Netron卖给了商业网站了，也有人说作者是想让大家看看Netron项目有多高的价值。

Netron Reloaded项目已经恢复了Netron项目在SourceForge上发布过的原有的文档和源代码的下载，only_me在2006-06-15说将在当晚恢复代码的CVS仓库，但是时至今日Netron Reloaded的CVS仓库仍然是一片空白。

Netron项目使用的协议是作者自己编写的一个协议，Netron Reloaded项目则采用了LGPL开源协议，尽最大可能地保证了和原协议的兼容，但是有人指出擅自改变原有代码的授权协议并不合适。

希望Netron Reloaded能够一路走好，也祝愿Francois能够找到一个更好的工作，能够有足够的时间和资源 working on diagramming stuff。

1.开源项目：The Netron Project(http://www.sourceforge.net/projects/netron)
说明：Netron是用C#开发的一套功能及其强大的图形库，目前最新版本是2005-07-29发布的v2.2.2036，如果你要用DotNet开发一个Diagram程序（例如开发一个类似Rose的建模工具），那么用这个图形库会是一个不错的选择。
具体功能可以自己运行代码中的Cobalt项目体验一下。

注意：Cobalt项目中有一个窗口是不符合CLS规范的，编译时会发生错误，我的解决办法是把Colbat项目的AssemblyInfo.cs中设置[assembly: CLSCompliant(false)]，这样可以编译运行。

可惜前段时间不知道什么原因其网站(http://netron.sourceforge.net)内容突然消失，取而代之的是一首英文诗，原因不明，这样原来的网站上很多文档都丢失了，现在只能看代码学习。

据作者在2006-01-19发表的声明，最新的3.0将在七月份发布，届时将是一个全新的图形库，不仅仅是功能的增强，连接口和架构都会完全改变——听上去似乎不是很美妙；但是现在网站消失了，不知道原定的计划是否仍然会继续执行。

2.免费工具：Editor4NAnt(http://www.codeproject.com/useritems/editor4nant.asp)
这是一个NAnt构建脚本的工具，可以对NAnt构建脚本进行可视化的编辑、测试和执行，类似贵得要死的Nantpad，不过是免费的，功能上也不比Nantpad差；这个软件的作者是班加罗尔的一个印度程序员，居然还是一个Project Leader。

遗憾的是需要DotNet Framework 2.0才能运行。

另外TortoiseSVN升级到了1.3.4，并终于推出了x64版本，在64位Windows下使用Subversion终于不用再打开32位的资源管理器了；昨天看到了digiking的《TortoiseSVN：Subversion客户端》，觉得“将Blame翻译成谴责真不好，其意思只是追根溯源”说得很对，把Blame翻译成“追溯”更合适。