问题的详细分析：
在文件的合并发生冲突时，冲突文件主要有以下几个版本：
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文件来判断是否进行了修改；第二个文件可以通过监视比较工具的进程进行判断。

在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。

目前网上找到的Subversion的配置说明中，关于用户权限控制都是基于Apache的User文件的或是基于svnserve.conf文件的，这种配置方式最大的问题在于用户信息保存在独立的文本文件中，维护不便（对用户的添加、修改等必须在服务器上执行，用户自己无法修改密码等），并且无法和其他系统集成。

 于是琢磨可不可以用公司现有的Active Directory对Subversion的用户进行权限控制，这样可以解决上面提到的几个问题。

 目前已经基本实现了对Subversion使用Active Directory验证，但是还有一些比较重要的问题没有解决，所以是“非完美解决方案”，放在这里抛砖引玉，希望能够有更好的解决方案。

 Apache不能直接调用Active Directory的，只能通过Active Directory提供的LDAP方式进行访问，因此需要在Apache中打开对LDAP的支持；

 Apache中自带了对LDAP的支持（默认情况下没有打开），但是官方自带的LDAP支持插件在Windows平台下有问题（我这里是经常造成Apache异常退出，服务终止）；因此在Windows平台下需要安装第三方的LDAP支持插件才可以。

 在网上找了一下，发现Apache的LDAP支持模块有以下几个可供选择（来源：http://nona.net/software/ldap/）：

我使用的是http://www.muquit.com的mod_auth_ldap，对其他的没有试过。

一、 安装（假定已经安装了Apache+Subversion）

1.        安装文件的获取：

mm_mod_auth_ldap for MS Windows binary：从http://www.muquit.com/muquit/software/mod_auth_ldap/mod_auth_ldap.html下载。

由于mm_mod_auth_ldap是基于Sun的iPlanet C SDK 5.08开发的，运行时还需要iPlanet C SDK 5.08的一些DLL，因此还需要自己下载iPlanet C SDK 5.08（http://www.sun.com/download/index.jsp?cat=Application%20Development&tab=3，需要注册才能下载）

2.        安装和设置（来自http://www.chinaunix.net/jh/49/618651.html）:

1)       将上面所说的两个压缩包中的DLL文件复制到Apache的modules目录中；

2)       在httpd.conf中加入 LDAP 相关模块的配置，就是增加如下一行：

    LoadModule auth_ldap_module modules/mod_auth_ldap.dll

二、 配置

如下是httpd.conf中Subversion段的配置，注意红字的部分就是LDAP的配置信息，具体意义参见注释；其他关于Subversion和Apache的配置资料请参见网上相关文章（例如http://cube316.net/blog/archives/200512/32）。

 <Location /svn>

    // 常规Subversion配置

    DAV svn

    SVNListParentPath on

    SVNParentPath D:\SVNStore

    AuthType Basic

    AuthName "Subversion repositories"

    # 不能使用svnaccessfile进行配置，原因见后

    # AuthzSVNAccessFile conf\svnaccessfile

    Require valid-user

    # 以下为LDAP配置信息

    # LDAP 协议版本，AD提供的LDAP为3

    LDAP_Protocol_Version 3

    # LDAP 服务器

    LDAP_Server 192.168.1.2

    # LDAP 服务器端口

    LDAP_Port 389

    # LDAP 基础DN

    Base_DN "dc=MainDC"

    # AD 的 LDAP 不允许进行匿名查询，因此需要提供一

    # 个 AD 中的用户名及其密码用于 Apache 的LDAP查询

    Bind_DN "cn=Administrator,cn=Users,dc=MainDC"

    Bind_Pass "password"

    # 供 Apache 查询的 AD Object 的属性

    UID_Attr "sAMAccountName"

    # 允许什么条件的 AD 用户访问 Subversion；

    # 这里设置只有scmuser组的用户才可以访问，但是并没

# 有成功，事实上只要是AD中的用户现在都可以访问，

# 不清楚问题出在哪里。

    require group "cn=scmuser,ou=groups,dc=MainDC"

</Location>

这样配置的意图是允许SCMUser中所有用户可以存取Subversion，其他的用户则不可以，但是事实上这样配置以后的实际结果是AD中所有用户都可以访问Subversion了，怀疑是require group中的LDAP Filter写的不正确，但是不知道该怎么写，目前就凑合着用了。

三、 问题
使用LDAP可以和其他系统比较好的集成，并且能够方便地对用户进行管理，但是这种方式对于Subversion很有问题，就是使用这种方式后无法使用AuthzSVNAccessFile来对Subversion进行目录级别的权限控制，据网上资料说是因为SVNAccessFile中的用户和组都必须在User文件中定义（参见http://svn.haxx.se/users/archive-2006-02/0586.shtml及其相关讨论），我想如果对Apache的授权模块进行自定义修改的话估计是可以的，不过目前我们对此要求不高，所以还暂时能够使用。

四、参考资料

1.        《开发服务器环境配置安装说明》（http://bbs.chinaunix.net/viewthread.php?tid=618651）

2.        《LDAP authentication module for apache》http://www.muquit.com/muquit/software/mod_auth_ldap/mod_auth_ldap.html

3.        《Subversion Users List Archives》http://svn.haxx.se/users/

首先，什么是链接文件？

在VS.Net中打开一个WinForm项目或者DLL项目（在Web项目中不能使用链接文件，感谢dudu指出），在随便一个项目中右击鼠标，选择“添加”→“添加现有文件”（抱歉，手头的机器太差，没有装VS.Net，所有的操作说明全凭记忆，如果有出入敬请原谅），随便选中一个文件，不要选“打开”，点击“打开”按钮右侧的下拉菜单，选择“链接文件”；

选中的文件已经添加到了你的项目中，但是这个文件和你平常添加到项目中的文件是不一样，这仅仅是一个指向你所选择文件的链接，相当于一个快捷方式；文件在你指定添加的位置上是不存在的，但是你可以照样地对这个文件进行编辑、编译等操作，和普通文件地使用并没有什么不同；

链接文件有什么用处？我能想到的大概有这么几个：

1.给可执行文件项目进行单元测试；
由于被测试的项目必须是DLL，才能够被NUnit单元测试项目引用而进行测试，因此如果你把逻辑代码放到了可执行文件项目中，NUnit就无用武之地了；

这种情况下要进行单元测试，可以新建一个DLL项目，通过链接文件把可执行文件下的所有文件都进行链接，然后把NUnit单元测试项目的引用指向这个项目，这样就可以用NUnit进行测试了；当你的可执行文件进行了修改的时候，“链接项目”的编译结果也会是最新的。

2.引用其他可执行文件项目
如果你要在自己的项目中引用其他可执行文件项目中的代码，除了将被引用项目的属性临时修改为DLL，编译后再改回来，似乎没有其他办法了。

类似上面对可执行文件项目执行单元测试的情况，我们同样可以使用链接文件解决这个问题：新建一个引用被引用的可执行文件项目的DLL项目，将你自己的项目引用指向这个新建的DLL项目即可；

上面两种情况，究其根本都是系统设计不当造成的，重构或者修改设计可以避免这种问题，但是实际中总是很难做到，用链接文件作为补救措施总还算是一种比较好的亡羊补牢方式。

3.给一个解决方案中的项目统一版本信息和签名信息
一个项目的版本信息和签名信息是在该项目的Assembly.cs文件中指定的，将所有的项目中的Assembly.cs文件都链接至同一个文件，以后只要修改这个Assembly.cs文件中的内容，就可以保证所有项目的版本信息和签名信息都是一致的。 NAnt 项目的 Build 过程就是这样的。

有个在世界范围内排前几名的国外公司在国内有一个生产厂 A，A 承担了该公司某种产品的大部分的生产任务，出于提高生产效率，降低生产成本……等等目的，该厂决定采用美国 B 公司的一套管理系统（一个很复杂的名称，我就称之为管理系统吧，大家都明白的）。

该系统是使用的是 .Net 平台，基于 B 公司的一个开发平台开发，这个开发平台是 B 公司针对类似于 A 公司的生产企业开发的一个通用型平台，对于特定的项目只要根据业务流程在这个开发平台上进行二次开发即可。

经过一段时间（我不知道具体是多长时间）的开发之后，该系统开始上线试运行，这时候问题来了：系统的稳定性先不说，产品的一个检测数据录入步骤就长达30秒，大大的制约了生产效率。

找 B 公司询问，B 公司开发人员称是你们的服务器不行，需要使用 Compaq 的 xxx 服务器；于是 A 公司去找中国 Compaq，中国 Compaq 的人说不好意思，这款产品我没听说，大概是不在中国销售的型号吧，我帮你跟美国总部问问；过两天打电话来了：老大，您这消息哪儿来的？那款服务器是美国 Compaq 的产品不错，不过要到明年上半年才开始销售呢……

最后好像服务器是采用了十几台服务器（具体怎么个组织法我就不知道了），然后还是三天两头问题不断：系统崩溃，数据同步失败，少有能正常运行的时候。

就在这样的状态下，B 公司在现场的维护人员少得可怜，据亲眼看到的我的同事说，当时系统已经在生产线上运行了，问题还很多，但是 B 公司在现场只有两个人，一个是经理级别的，不怎么写代码，另一个则是新手，基本上等于什么都不懂。

最终的结果是试运行了大半年了，这套系统仍然没有达到预期的目标，从同事给我说的情况来看，该系统几乎就是一个废物。

最近，B 公司向 A 公司发出通知，该项目的合同和贵公司支付给我们额费用都将到x年x月x日终止，届时我们将终止对该项目的维护……而到此时为止，A 公司在这个项目上的投入（硬件、软件、开发费用等）已经超过了 2000 万 RMB。

不过 B 公司还没有太过于“甩手”，告诉 A 公司，我们可以将该项目转给 C 公司，这是我们的一个合作伙伴，他们可以继续把这个项目维护下去，当然，合同和费用需要另外协商……C 公司已经来人考察，确定是否接手该项目。

这个项目问题出在什么地方？我不知道，但是肯定不在技术或者经验上，B 公司的经验和技术绝非泛泛之辈（否则 A 公司也不会选择他们），我看过他们的开发平台，没有相当丰富的经验，没有很强的技术是做不出来的（仅凭我个人的感觉，我没有那个资格也没有那个实力去评判）；但是为什么搞的这么糟糕？有一件小事可以让我们管中窥豹：半年前有一个报表需要修改，修改内容是将报表上的某个选择项从 DropDownListBox 的单选方式改为 CheckBox 多选方式，修改要求提出后 B 公司多次声称这个选项没办法改，于是这个要求就在 提出→拒绝→再提出→再拒绝 的死循环中始终都没有修改过；上个星期 C 公司的考察人员中有一个小伙子花了一下午的时间，完成了这个报表的修改（&%#$^&#$%34），同事说“A 公司那帮哥们脸都绿了”。

现在的状况：B 公司开发这套系统的核心人员——该系统的核心业务部分就是这位老大一个人（！？）在开发平台上完成的——跳槽了（看来这种事不只中国有啊），但是系统的二次开发没有什么文档留下来，现在的开发人员每天都在猜测这位老大当初为什么要这么设计（这个场景似乎很熟悉？）；该系统列出了一个很长的修改清单，有一个 Team（不知道是 A 公司的还是 B 公司的，没有问同事）每天都扑在上面修改，但是系统仍然不稳定，上个星期在线数据库和查询数据库之间的同步失败，一直到昨天仍然没有恢复，结果后台的一些系统就一直因为没有数据可用而处于瘫痪状态；A 公司内部大家都已经选好了公认的替罪羊，一旦项目宣告失败，哼哼……

于是把 SQLite 的一堆东西下载下来看了看，建表、添加数据都很简单，也有 .Net 的驱动程序，看上去一切都很完美——不过，怎么对数据库加密码呢？

开动 Google，找了半天，找到这么一个结果：http://article.gmane.org/gmane.comp.db.sqlite.general/11374，第二个回复里写的：
>>if you send Dr. Hipp money you can get a version that is protected by a password. It seems like an equitable trade, with everybody happy in the end.

看来想免费加密是没戏啦。

>>If your data is valuable enough to be worth somebody's time to steal, I think it should be valuable enough for you to protect it properly.

这话是没错，不过，不过，俺还是想找一个能免费使用的，可以比较好地加密地数据库……

我更喜欢第一种方式，毕竟Translater和Developer是不一样的，有可能Translater对于程序的使用很精通很感兴趣，但对于程序开发根本就一窍不通，所以把翻译工作做的最为简单最好的。