TortoiseSVN与Subversion 1.5

http://www.uml.org.cn/pzgl/200806137.asp 许 多人在谈论TortoiseSVN以及它在合并跟踪方面的计划，有些人可能不知道TortoiseSVN，TortoiseSVN是Windows下的一 个Subversion客户端。它嵌入到了WindowsShell而且让Subversion客户端命令出现在Windows浏览器和任何打开保存对话 框的右键当中。TortoiseSVN是赢得Sourceforge.net Community Choice Award2007的伟大工具，你可以从openCollabNet下载，它也是CollabNet的一系列Subversion集成支持的一部分。 我 自己一直使用TortoiseSVN，所以我一直很关心TortoiseSVN对于合并跟踪的计划，他们的网站有一些信息，但是我联系了 TortoiseSVN的项目领导Stefan Küng，向他询问了目前的状态，下面是他的反馈和一些抓图（感谢Stefan）： -------------------------------------------------------------------------------- 合并跟踪通常是被Subversion库完成，而我们用户不需要知道。用户不会看到Subversion会忽略掉已经从主干合并到分支的修订版本，所以对于TSVN的界面没有太多事情可以做，需要给用户显示更多的地方，我们已经做了，另外，我们以及已经尽力隐藏细节。 现在我们已经完成的: 日志窗口，当我们从合并窗口选择需要合并的修订版本，会使用灰色而不是黑色来显示已经合并的修订版本，这可以提示用户灰色的版本已经不需要合并了（再一次）。 日志窗口会缩进现实合并修订版本，每一个缩进级别显示了一个合并级别，这个UI也许将会在1.5最终发布前修改，因为我对现在的缩进样式不是非常满意 - 很难察看不同的级别，也许我会添加一些竖线或其他什么来改进缩进。 当显示blames时，合并行会使用斜体显示，用户可以选择显示合并路径的所有行。 -------------------------------------------------------------------------------- TortoiseSVN 网站的夜构建与从Merge Tracking Early Adopter Program下载的Subversion 1.5的预发布二进制程序可能不会一直可以工作，下一周我们会更新Subversion 1.5二进制程序到最后开发状态，我们会将根据最后Subversion构建的内容发布TortoiseSVN构建。 另外一件事，在10月 30号，CollabNet会做另一个Subversion 1.5的webinar，会覆盖Subversion 1.5的高级分支和合并，这个webinar会紧跟上个月的关于分支策略的webinar，也会回答当时大多数人问的问题。 这里注册。 Subversion 1.5的合并跟踪与svnmerge.py Filed under: Subversion Server, Subversion in the Enterprise, Subversion Client — rocksun @ 10:52 pm 在”Subversion 1.5的分支与合并”webinar中，两个问得最多的问题是： Subversion 1.5的合并跟踪特性与svnmerge.py有什么区别？ 有移植工具吗？ 我现在正在慕尼黑参加SubConf之前的CollabNet’s Subversion Power Workshop，第一个会议专门针对Subversion，在合并跟踪会议中覆盖了两个问题。 在 讨论Subversion 1.5的合并跟踪与svnmerge.py相比的优势之前，有一点很重要的事情我要说的就是svnmerge.py是一个非常有用的工具，它由 Subversion成员贡献和维护。我们非常感谢贡献者，但是Subversion 1.5确实提供了许多超过svnmerge.py的优势： SVN 1.5合并跟踪位于每路径的级别的粒度，跟踪文件级别的合并，而svnmerge.py只跟踪整个branch的合并信息，而不会跟踪更好的级别（例如文 件），这允许SVN实现cherry picking，svnmerge.py不支持的东西。 svnmerge.py经常不会正确的合并合并属性（就像svnmerge-integrated和svnmerge-blocked），在跨多个分支的合并时会导致属性冲突，SVN 1.5解决了这个问题。 SVN 1.5支持第三方工具，例如冲突解决的回调，如果出现合并冲突，Subversion可以调用你的GUI客户端，而客户端会启动冲突解决工具。 Subversion可以调用你的GUI客户端，并使之调用冲突解决工具。这改进了工作流程和可用性。你可以试用 CollabNet的新GUI合并客户端来查看SVN 1.5的合并与GUI工具的集成。 SVN的合并跟踪包含了更详细的审计，例如查询合并历史来回答何时，何地做了什么合并。 一个将svnmerge.py的合并跟踪历史移植到Subversion 1.5的工具前几天已经被提交，它可以做什么？ 将最新的合并历史转化为多个分支。根据历史，分支最后一次合并的信息都是最重要的信息，因为它允许在下次合并时更容易，如果你希望保持简单，并且只移植最新的合并历史，你可以。 移植工具也可以扫描整个版本库来寻找合并历史，或接受一系列路径前缀来查看：svnmerge-migrate-history.py /path/to/repos trunk tasks branches 我们在Merge Tracking Early Adopter Program的下载小节上传了一个脚本的拷贝，你可以下载并在你的版本库上（不是生产库，Subversion 1.5依然在开发中）测试，他应该工作正常，但是如果发生任何问题请告诉我们。我们知道一个限制：不要在已经有合并历史的Subversion 1.5版本库上运行，这还没有测试过（只是：你干吗要这么做？）现在，只有.py脚本，但是Subversion开发者以后会发布一个Windows可执 行程序。 Subversion基于变更集的合并 也许你已经度过了我上周的blog，Subversion merge made easy。在那篇文章里，我作了一些CollabNet Merge client的链接，得到了许多下载并试用客户端的反馈。 本 周，我们引入了一个合并客户端扩展的预览，允许你执行基于变更集的合并，随着客户端合并的扩展，CollabNet企业版Project Tracker的用户可以指定项目跟踪作品作为合并过程的输入，而不是只能指定一组修订版本。这确实是执行特定类型合并的简单方法，将会导致一些有趣的新 工作流程和商业流程。 如果你已经安装了合并客户端，你可以访问相同的安装站点，得到变更集扩展，我已经写了这个客户端的一个总揽，也有一些细节和截图，点这里得到变更集扩展的总揽。 当你需要Subversion 1.5才能得到合并跟踪的好处时，你可以现在就在CollabNet企业版使用变更集扩展，所以试一下吧，然后告诉我们你的想法。 Subversion合并将更简单 这是Subversion的CollabNet 的工程团队以及Subversion社区忙碌的几个月，就像我们夏天发表的文章，我们整个团队正在为Subversion 1.5工作，特别是为合并跟踪特性。 回 到春天，我们在openCollabNet开始了Merge Tracking Early Adopter Program，我们希望让用户能够尽早尝试合并跟踪代码，并给CollabNet和Subversion社区提供反馈，这个计划非常成功，提供了一些有 价值的反馈，并已经集成到Subversion1.5的合并跟踪发布中。上一周，我们在合并跟踪站点更新了Subversion的beta程序到一个最近 的版本，并启动了新一回合的测试，如果你还没有下载，请下载它们并试用，帮助社区发布1.5还不晚。 本文的标题是”Subversion merge made easy”，这让我。随着Subversion1.5的各项工作的进行，另一个CollabNet的项目正在新的GUI合并客户端程序上工作，今天我们发 布了beta版本，作为MergeTracking Early AdopterProgram的一部分。这个客户端包含了很多特性，这里不一一列出，请访问合并跟踪站点的文档。这个文档解释了如何安装客户端，并且提供 了对它的特性的一个深度总揽，我鼓励你下载这个客户端并且试用。使用这个论坛来为合并跟踪项目提供反馈，询问问题，报告问题等。如果你已经尝试了客户端， 你也就自动测试了Subversion 1.5合并跟踪特性，将会加速版本的发布。 最后，因为我们在讨论更简单的合并与跟踪，我只是希望提 一下即将到来由我的两个CollabNet同事参与的webinar– Bob Jenkins和Auke Jilderda，他们都在合并跟踪特性上贡献了许多主意和反馈，也辅助了openCollabNet的merge tracking early adopter program，他们的webinar一定将包含对于Subversion分支与合并的有价值观点。 SCPlugin: Subversion for the rest of OS X 现 在openCollabNet的Mac社区提供了命令行Subversion的完全最新安装程序，那GUI的访问呢？这是Macintosh，当然有许多 独立运行的GUI客户端，一个标准集成到Apple的Xcode，以及Eclipse，JDeveloper,，NetBeans的插件，以及其他程序， 但有没有基本的Finder访问？Windows用户已经用了很多年TortoiseSVN，另一个Tigris项目naughtysvn可以工作在 linux的Nautilus桌面环境，为什么Mac不行呢？ “为什么不”真的吗！介绍一下SCPlugin：对于其他OS X的Subversion！ tigris.org的 SCPlugin项目已经持续稳定开始工作，带来Finder插件方式的Subversion能力 -你的整个桌面是可以使用Subversion的，我们刚刚发布了0.7，一个beta版本，但是我们相信已经能够提供支撑日常工作的所有功能。 那SCPlugin是什么？ 我们为每个Subversion控制下的文件和目录的Finder图标添加了徽章，这个徽章提示文件的状态：干净检出，修改了，冲突中等等。 我们也扩展了Finder的”上下文菜单”（你知道…control-click或click且不放，或如果你的鼠标有多个键的右键），有了Subversion命令，在弹出菜单中存在的命令应用到你选择的文件和目录。 通过这个插件，OS X Finder加入了Subversion的世界。 一 些技术提示：可以与Subversion 1.4.x工作在OS X 10.3.9和10.4.x（不要与其他Subversion 1.3的客户端混合使用），这是一个beta版本：一些事情可能不正常，加入users@scplugin.tigris.org邮件列表，提供问题或使 用记录。 Subversion 1.5 - 解决冲突 如果你是这个blog的常规读者， 你一定不会怀疑我们会在今年的晚些时候发布Subversion1.5，包含合并跟踪这个大特性。技术上讲，合并跟踪是一项很大的内部特性，唯一例外就是 对于UI中合并过程的简化。实现这个特性导致我们花费大量时间认真考虑整个合并过程和随之而来的技术上不属于合并跟踪的改进，这让我们写下这篇blog， 来描述Subversion 1.5是如何让解决冲突的更简单。 Subversion 1.5带来了两项对于解决冲突的改进，第一个是svn resolved增加新的–accept选项，你可以通过指定一个文件的版本来解决冲突，另一个特性是交互冲突解决。 svn resolved 当 Subversion在一个文件生成冲突时，你需要做出一些动作来解决冲突，然后运行svnresolved命令告诉Subversion你做的事情，就 像前面说的，这个命令现在包含了一个–accept选项，允许你在确定冲突已经解决的同时选择文件一个特定的版本，这个特性最常见的用法就是对付二进制文 件。 一个我会使用这个特性的例子是当我有一个发布分支使用了与trunk不同版本的二进制文件，例如JAR文件，例如，我的分支也许使用某 个库的1.x版本，而trunk使用2.x版本，当我将修改从trunk转移到分支时，会包含这个库的文件，我会在分支上得到冲突，如果没有这个命令，我 需要在工作拷贝手工的拷贝/改名正确版本的文件，然后运行svn resolved命令，通过这个改进，我可以告诉Subversion这样做，例如： svn resolved –accept=left my-library.jar 这样会代替branch中使用的文件来解决冲突，除了二进制文件，其他用户会在脚本中实现自动合并到某个分支类型，显然这个特性不是用来在你使用三方区别/合并工具用来解决冲突时使用，然而，下个特性就是解决这中场景。 交互式冲突解决 svn resolved特性的开发确实使得开发者思考这种特性是如何集成到合并过程本身的（顺便说一下：所有这些特性可以应用到update和switch命令，因为他们也会产生冲突），这导致了交互冲突解决特性的产生，下面是这个特性的例子： svn up U contrib/client-side/svnmerge/svnmerge_test.py Conflict discovered in ‘contrib/client-side/svnmerge/svnmerge.py’. Select: (p)ostpone, (d)iff, (e)dit, (h)elp : h (p)ostpone - mark the conflict to be resolved later (d)iff - show all changes made to merged file (e)dit - change merged file in an editor (r)esolved - accept merged version of file (m)ine - accept my version of file (t)heirs - accept repository’s version of file (l)aunch - use third-party tool to resolve conflict (h)elp - show this list Select: (p)ostpone, (d)iff, (e)dit, (h)elp : t G contrib/client-side/svnmerge/svnmerge.py Updated to revision 25685. 在这个例子里，我运行了update命令，且得到了冲突，这是因为我本地修改了文件。这个update过程会提示我解决 这个冲突，也提供了许多选项来辅助我。在这个例子里，我使用了(h)elp选项来显示更多的选购向，例如在svnresolved特性里，我可以选择某个 文件的版本（对于二进制文件类型很有效），但是现在我也可以选择看一下diff，或者打开一个编辑器或甚至启动一个3方区别工具，后面的两个选项需要设置 EDITOR或SVNMERGE的环境变量来启动相应的工具。 如果你采用这个选项来编辑文件，当你结束时，你可以告诉Subversion你已经解决了冲突，如果你只是希望Subversion将文件标记为conflicted，你也可以使用(p)ostpone选项，这样就可以在以后解决冲突，就像你现在的方式。 你有很多方法可以关闭这个特性，第一是添加–non-interactive选项，有这个选项时，Subversion会仅仅创建冲突，而不会在过程中提示你。对于自动脚本或你不希望提示时非常有用，你也可以通过运行配置文件关闭这个特性： [miscellany] interactive-conflicts = no 通过设置这个配置文件，你就从本质上回到1.5之前的行为方式。 结论 还 有一点我没有谈到的是这Subversion的这些特性都有SubversionAPI，所以图形化客户端可以很容易的实现同样的特性，例如我们已经将交 互冲突解决集成到了CollabNet Desktop - EclipseEdition，随着Subversion1.5版本发布日期的临近，我可能会在另一个帖子里介绍其他Subversion图形客户端的这 个特性，类似的，我肯定TortoiseSVN会很快集成这些特性，做出伟大的事情来。 第二次机会和Subversion 我们一直在犯错误，如果生活总会给你第二次机会，或者改正错误的机会，那不是很棒吗？幸运的是你使用了Subversion，大多数情况下，你可以轻松的修改错误。 假 设我们的Subversion不能做的很简单，你犯了一些错误，但是删除了所有发生过的轨迹，Subversion记录在某个时间点的版本库，而且历史不 可变，也就是不可以修改。很不幸，这意味着一旦你不小心提交了包含密码的配置文件，你可以编辑文件并再次提交，但是Subversion永久保留最初的提 交，包含密码。删除这些东西的唯一办法就是把版本库dump到一个文件，从dump文件中小心的删除那些内容，然后重新加载版本库。这不适合胆小者，但是 可以做。大多数Subversion安装使用提交钩子在每次提交时发送修改细节邮件，这很有价值，即使Subversion让删除轨迹变得容易，也无法避 免邮件发送到全世界。 一个Subversion可以简单修正的常见错误就是对于删除的恢复，我恨这一点，但是几个月以前我不小心将 Subclipse版本库的整个branches目录删除了，你可以在这里看到使用ViewVC看到血淋淋的细节，我知道我可以简单将它找回来。如果你查 看以前的链接，你可以看到我在修订版本2981提交了删除，我需要做的就是将其从2980拷贝出来。 svn copy -r2980 http://subclipse.tigris.org/svn/subclipse/branches@2980 \ http://subclipse.tigris.org/svn/subclipse/branches 这 个命令的意思是，”将2980修订版本的branches目录拷贝到branches（目前不存在的目录）”，你需要在第一个URL中添加@2980，它 告诉Subversion的历史跟踪规则找到这个目录。如果你省略这个参数，Subversion会查看版本库的HEAD修订版本，你可以在ViewVC 的 这里看到提交的结果，请注意你可以看到项目是从修订版本2980拷贝而来。 所以就是这样将删除的东西恢复，如果事情更加细致该如何？你 修改了一组文件，但是你不希望有这些修改。你希望从本质上”回退提交”，这对于Subverison非常简单，你可以通过所谓的”反向合并实现”。本质上 讲，就是使用svn merge命令将修订版本号反转过来，对于命令行用户，这种情况已经在Subversion book中详细论述，请见回退修改部分，这一小节也有一些其他的例子，很值得一看。 Subclipse和TortoiseSVN在其图形界 面中提供了更简单的方法，1月份我在我的个人blog里写了一个类似的例子，它介绍了使用Subclipse GUI完成这个功能的方法，如果你希望知道如何使用GUI完成这个功能可以看这个帖子。 如果说我希望这个帖子能带来什么，我希望是增加Subversion对于数据安全的信心，继续修改并提交，那就是Subversion的工作，如果你犯了错误，不必担心，Subversion一直会给你第二次机会。 来自问题盒：Subversion锁定 在 CollabNet，我们经常会在许多不同途径（webinar，培训等）得到很多Subversion的问题，我们尝试尽快地回答问题，但是有时候我们 需要记录未回答的问题，所以就像以前在这个blog里所做的，我们尝试回答这些排队的问题，主要关注于Subversion的锁定特性。 首 先，允许我首先从高级别总结一下锁定特性，Subversion采用的缺省版本控制模型是”拷贝-修改-合并“模型，用户会从版本化目录中检出个人工作拷 贝，然后提交修改，只需要担心偶尔发生的对于同一个文件的修改。锁定（有时候我们称为”保留检出”）允许Subversion用户跳出缺省模型，而采用” 锁定-修改-解锁“模型，这样多个用户顺序提交给定文件，所以冲突不会发生。后一种模型是VisualSourceSafe中经常使用 的，Subversion的锁定特性通过允许用户声明对一个文件的修改排他锁来完成这个功能（然后之后放弃这个权利）。 推荐使用锁定吗？ Subversion开发者不会真的开发新特性来违反社区自己的推崇和最佳实践，而锁定特性（Subversion 1.2添加）是有意开发的，问题可以这样描述：”何时推荐锁定？”为了回答，我们来看一下两种控制模型赞成和反对的理由。 拷贝-修改-合并具有较少管理和流程的特性，所有的人可以自由修改文件，只是在发生冲突时解决。不幸的是，当冲突发生时，解决冲突的代价会有很大的不同，从不费任何脑到我浪费了一周的工作，这取决于冲突文件的格式。 当 使用锁定-修改-解锁时，每一个人需要付出流程代价，如在需要编辑时明确锁定文件的，而在结束修改时解锁文件。如果用户不小心，这可能意味着一个用户可能 保留不必要的时间来编辑文件，这会妨碍项目组的生产力，也会需要管理员的干涉。但是在正面，你不必在解决冲突上花费力气，因为冲突（只会发生在多个文件提 交同一个文件的修改）不可能发生。 就像生活中的很多事情，两种模型的平衡会是最好的结果。Subversion的内置上下文修改合并算法可 以处理大多数多个用户同时修改同一个文件的情况，当然文件是文本文件或其他人可读格式。对这些文件，使用拷贝-修改-合并（不锁定文件）可以节省用户投入 到流程的步骤，鼓励协作并防止管理投入。但是对于处理冲突代价很高的文件，例如不可读文件格式，锁定和解锁会比解决可能发生的冲突轻松许多。 Subversion支持保留检出吗？ 就 像前面提到的，很多人将Subversion的文件锁定特性当作”保留检出”，但是这非常不准确的。在具备保留检出功能的版本控制系统，术 语”checkout”不仅仅是在你的计算机得到一个版本化的文件，也是获得修改文件的权利，一个保留检出是同样的，除了你保护的修改权限是排他的 -文件对其他用户是只读的。Subversion使用这个术语很古怪，缺省情况下，如果你从Subversion版本库检出一个文件，你可以编辑它，你可 能无法提交它，一方面因为你没有授权，也有可能是你的本地工作拷贝已经过时了，或者是本文相关的 - 因为其他人锁定了它。 但是等一下，如果有其他人锁定了文件，为什么Subversion允许我们花时间修改它？ 你 可以运行’svn status –update’或对文件或版本库URL运行’svninfo’来查看被其他人锁定的文件，但是Subversion不会坚持这些信息到工作拷贝，在你最 后询问服务器锁定和提交修改之间一定有一个时间差，锁定文件节省了处理冲突或浪费编辑的时间，但是不能帮助协作者来解决你以前面对的情形。 处 理这种场景的最佳方法是使用Subversion的文件属性-svn:needs-lock。通过在文件上设置这个属性，你可以告诉Subversion 这个文件会导致你和你的协作者需要在修改之前获得这个文件的锁，设置svn:needs-lock属性的文件在工作拷贝（在OS的文件系统意义上的）首先 会是只读的，这样足以让行为良好的编辑软件不会修改这个文件，当你将文件加载到软件时，软件会提示文件只读，你会记起你需要使用”svnlock”锁定文 件，通过这样做，Subversion会改变工作拷贝中的文件系统访问控制，它不再是只读得了，你可以修改这个文件了。当你提交并释放了文件的锁 定，Subversion重新让它在工作拷贝回到只读状态。 作为最佳实践，我推荐你小心的评估svn:needs-lock属性的有无，如果一个文件没有包含这个属性，你确实需要锁定它吗？如果你确实需要锁定文件，有其他人会从工作拷贝的只读属性中获益吗？ 请 注意，svn:needs-lock属性不会导致Subversion要求文件提交时是锁定状态，它只会作用于客户端文件系统的只读问题，前面我也说了 svn:needs-lock发挥作用需要你使用行为良好的软件。但是如果你的软件忽略只读文件系统位-或者你手工修改文件许可位 -你或许不会发现在修改之前获取锁会失败，Subversion会很高兴得允许你提交修改。（如果你的软件这样运行，请考虑告诉它的开发者！） 可以锁定模块/目录，还是只能是文件？ 很不幸，此时在Subversion里你只能锁定文件。 这 种不幸的原因很清楚，因为你不能锁定目录，许多人会这样工作 - 锁定目录下的所有文件，不管对于特定文件集是否必要，这样在Subversion中会有一些性能问题。现在Subversion还不支持多条锁定路径操作 的原子化- 如果200个文件中有126个锁定因为一些原因（很可能是被别人锁定了）失败了，你会得到部分锁定。对于经常这样做的人来说，应该考虑”svn lock”不接受recursive子命令的事实，这不是Subversion开发者不小心，如果你希望整个目录的访问限制，请使用路径为基础的访问控制 方法。 你能告诉Subversion你希望锁定所有文件吗？ 是，你可以，但是决定这样做之前请读一下前一个问题的答案。如果 你觉得你确实需要，你可以将所有的文件设置svn:needs-lock属性。（你可以参考使用客户端的自动化属性功能。）读一下前面的纪录，为什么 Subversion那些文件需要锁定。作为选择，你可以编写一个pre-commit钩子脚本可以检查提交文件是否已经被锁定。（你可以相信 Subversion来检查提交者确实是锁定的拥有者。） 可以锁定特定文件类型（例如所有的*.doc文件）吗？ 当然，看前一个答案，只需要限制自动化属性的范围，或使用钩子基础的提交验证来确认感兴趣的文件类型。 Subversion 1.5的特性：Changelists 典型工程师的一个特质就是会对潜在问题区域高度敏感，对于软件工程师来说，这通常意味着当在代码块中工作时会在间接视觉中定位可能的问题，这是祝福也是诅咒。你希望bug被修正，但是我们经常会在追求完美的过程中脱离了主要任务。 另一个开发者生活的事实就是他们总有许多事情无法按时完成，而且每一件事都对某些人有最高的优先级，因此，我们发现自己经常在同一时间作许多事情，结果所有的事情进展都会很缓慢，至少你可以凭良心和强迫的微笑：”正在处理，我正在为此事工作。” 我的管理读者，我必须承认我对那些问题绝对没有办法，毕竟这是一个技术blog。但是我可以（也会）告诉你一个即将到来的Subversion特性，可以减少这类开发者的环境转换：changelists。 无 论什么原因，开发者经常会在任何给定时间修改代码中显著不同的东西，经常是每个修改没有精细的保存在一些模块中，没有安全的与其它修改分离。修改的组会重 叠，修改同一个模块的不同文件，甚至是同一文件的不同行。开发者有许多工作方法可以采用来保持任务的组织性，一些用户使用同一个版本库的不同工作拷贝来保 存每个单独的修改过程，另外一些人会在版本库创建一个特性分支，使用单独的工作拷贝经常会指向某个分支，也有一些人使用diff和patch来备份和恢复 未提交的修改，使用补丁文件来关联每一次修改。这些方法都有其利弊，更大程度上，要做的修改的细节制定了区分它们的方法学。 但是在 Subversion1.5我们有了一个新特性叫做”changelists”，另一种处理混合的方法。changelists基本上是以关联多个文件一 起为目的的，应用到工作拷贝文件上的任意标签，Gmail用户对于这个概念已经非常熟悉，Gmail没有提供传统的目录为基础的邮件组织机制，在 Gmail里，你可以为邮件附加任意的标签，所以多个共享同一个标签的邮件成为同一个组的一部分，所以察看具备相同标签的邮件成为一个简单的用户技巧。许 多Web2.0的站点具备类似的机制 -考虑YouTube和Flickr等站点使用的”标签（tags）”，blog条目的”分类（categories）”等等。现在的人们知道组织数据的 困难，但是数据的组织应该是一个灵活的概念，以前的文件目录组织方式对于大多数应用过于严格了。 所以Subversion的changelist支持允许你： 给需要与changelist关联的文件应用标签（labels）， 删除标签，而且限制子命令操作的对象仅限于特定标签。 例如，作为我今天要完成任务的一部分，我需要修正一些ViewVC的diff察看相关功能的问题，我的工作需要修改一组文件。 $ cd projects/viewvc$ svn statusM lib/vclib/ccvs/__init__.pyM lib/vclib/__init__.py$ 但是当我测试这些修改的时候，我发现一些注释支持的代码不能正常工作。因此，就像前面提到的，此刻为了转换上下文环境并修改次要问题我可以做很多事情，为了描述我们将会使用changelists。 首先，我想创建一个changelists与我已经修改的文件关联，这样可以帮助我将次要问题将要修改的文件区分开来。 $ svn changelist diff-fixes lib/vclib/ccvs/__init__.pyPath ‘lib/vclib/ccvs/__init__.py’ is now a member of changelist ‘diff-fixes’.$ svn changelist diff-fixes lib/vclib/__init__.py Path ‘lib/vclib/__init__.py’ is now a member of changelist ‘diff-fixes’.$ svn status— Changelist ‘diff-fixes’:M lib/vclib/ccvs/__init__.pyM lib/vclib/__init__.py$ 就像你看到的，”svn status”的输出反映了新的分组。 现在我开始修正次要问题，需要我修改三个文件，我还没有准备好提交任何文件，所以我对第二次修改也创建一个changelist。 $ svn changelist blame-fix lib/vclib/ccvs/blame.pyPath ‘lib/vclib/ccvs/blame.py’ is now a member of changelist ‘blame-fix’.$ svn status— Changelist ‘blame-fix’:M lib/vclib/ccvs/blame.py— Changelist ‘diff-fixes’:M lib/vclib/ccvs/__init__.pyM lib/vclib/__init__.py$ 现在，独一无二的分组看起来很好，但并不是完全有用。如果我希望只是察看diff相关的代码变更，在”svn diff”中，我仍然需要我所修改文件的明确文件名。 $ svn diff lib/vclib/__init__.py lib/vclib/ccvs/__init__.py 这对于两个文件并不太难，但是如果是20个文件呢？ 幸运的是，Subversion 1.5的changelist支持更加彻底，我可以使用新的–changelist选项来限定许多子命令只关联给定changelist的文件，结果就是更简单的命令行，以及更简单的来俯瞰我希望检查的文件。 $svn diff --changelist diff-fixesIndex:lib/vclib/ccvs/__init__.py===================================================================—lib/vclib/ccvs/__init__.py (revision 1157)+++lib/vclib/ccvs/__init__.py (working copy)@@ -112,8 +112,8 @@ temp2 =tempfile.mktemp() open(temp2, ‘wb’).write(self.openfile(path_parts2,rev2)[0].getvalue()) - r1 = self.itemlog(path_parts1, rev1, {})[0]- r2= self.itemlog(path_parts2, rev2, {})[0]+ r1 =self.itemlog(path_parts1, rev1, {})[-1]+ r2 = self.itemlog(path_parts2,rev2, {})[-1] info1 = (self.rcsfile(path_parts1, root=1, v=0), r1.date,r1.string) info2 = (self.rcsfile(path_parts2, root=1, v=0), r2.date,r2.string)Index:lib/vclib/__init__.py===================================================================—lib/vclib/__init__.py (revision 1157)+++ lib/vclib/__init__.py (workingcopy)@@ -240,7 +241,7 @@ def readline(self): return self.fp.readline()- def close():+ def close(self): try: if self.fp: self.fp.close()$ 就像你预期的，我可以在”svn commit”中提供同样的–changelist选项。 $ svn ci -m "Fix some diff-related oopses." --changelist diff-fixesSending lib/vclib/ccvs/__init.pySending lib/vclib/__init.pyTransmitting file data ..Committed revision 1158.$ 同时，我的其他changelist依然没有被打扰。 $ svn st— Changelist ‘blame-fixes’:M lib/vclib/ccvs/blame.py$ 许 多Subversion客户端子命令（commit, diff, info, lock, log, proplist, propget,propset, status, update, …). ）出现了新的–changelist选项，而且，当然也有了新的”svnchangelist”子命令，用来从changelist添加和删除（通过一个 –remove选项）文件。Subversion没有强制你使用changelist，就像大多数事情，Subversion只是提供给你这个工具，让你 决定是否使用它。总之，这个特性给了Subversion用户，特别是有Perforce经验的用户 - 同时管理多个进行工作的一个简单方法。 changelist 支持也有一些限制，首先，这个特性是路径粒度的特性，如果你发现你有同一个文件的重叠修改，你需要找出不同的方法来处理重叠。同样，changelist 只是对于特定工作拷贝私有 - 无法自动与其他用户分享你的changelist定义，但是解决这个特性不是什么大问题 - 如果你需要共享进行中的工作，使用版本化的分支。 Subversion 1.5的合并审计 我们上周将Subversion合并跟踪特性提交到主干的过程很漂亮，Hyrum Wright是GoogleSummer of Code计划的一个学生参与者，他签约来提供合并跟踪的“Merge Auditing”特性，你可以在功能规格上看到一些细节，但实际上它是关于在svn log和blame输出中添加对于合并跟踪信息的智能和意识，在合并跟踪计划中，这是1.5之后的特性，它是任何人希望在码基中看到的特性，但是我们感觉 版本的发布和核心功能的优先级更高。 不管怎样，在这种情况下我们可以手到擒来了，Hyrum，我应该将其添加为完全提交者，他在 svnlog中支持这个功能做出伟大的进展，并且已经将这些修改提交到了trunk，此外，我们为合并跟踪早期采纳程序创建的样例版本库已经帮我们完成了 这个特性的操作指南，因此我们有一个文档完好的样例版本库，以及匹配的图像，Hyrum可以用来饮用，它可以帮助他精炼这个特性并使之工作正确。 上面的图像是我们样例版本库的历史，如果你仔细观察，你会发现r14对于trunk的提交是这个特性发生作用的有趣实例，这个提交从分支合并而来，这个合并包含了另一个分支的附加合并，如果我运行这个命令（注意新的-g 选项）： svn log -g -r 14 $REPOS/trunk Here is the new output: ------------------------------------------------------------------------r14 | merger | 2007-05-30 15:48:11 -0400 (Wed, 30 May 2007) | 3 linesMerge branch b - product roadmap and update about pageCommand executed: svn merge $REPOS/branches/b————————————————————————r13 | buser | 2007-05-30 15:46:48 -0400 (Wed, 30 May 2007) | 1 lineResult of a merge from: r14Update info about our company————————————————————————r12 | merger | 2007-05-30 15:45:19 -0400 (Wed, 30 May 2007) | 3 linesResult of a merge from: r14Merge branch a - product roadmapCommand executed: svn merge $REPOS/branches/a————————————————————————r11 | auser | 2007-05-30 15:43:00 -0400 (Wed, 30 May 2007) | 1 lineResult of a merge from: r14, r12Add product roadmap———————————————————————— 需要注意它是如何包含修订版本r14的合并信息，此外，那些修订版本如何使另一个合并的结果。图形客户端，例如我们的CollabNet Desktop - Eclipse Edition 和TortoiseSVN一定可以在他们的UI中显示有用且有趣的图像。 这是Hyrum梦幻作品，继续努力，我已经等不及看到blame的实现了。