Filed Under (General) by rocksun on 29-04-2008
在4月24日，Subversion开发社区发布了第一个Subversion 1.5的候选发布。你可以看到这个邮件列表的声明，你会注意到发布的标签是RC4，你可能会奇怪如果你错过了RC1-3。答案是否，这是第一个官方的发布，我们在发布任何发布之前进行了内部复审，提交构建和测试并为这个发布候选投票，在开始的三次尝试中，有人发现了一些不喜欢的事情，所以我们选出了这个发布，因为版本号很廉价，我们在尝试时增加了版本，这样我们就和其他人使用的没有任何混淆了。
无论如何，这是发布的一个重要的里程碑，离最终GA的很近。这个发布可以进行正式的使用，将会持续至少四周。你可以阅读我们网站上的hacking指南中的发布稳定过程，作为发布候选阶段的一部分，我们开始了发布说明最终，你也可以在网上看到这个，这个文档对于发布有许多纵览信息。
就像我们在1.5开发生命周期中，CollabNet提供了此版本的二进制程序，我们希望让用户测试这个发布来提供反馈。请提供反馈，通过合适的反馈，可以帮助我们知道人们实际测试这个候选者。有些时候，如果我们不能得到足够的反馈，我们会延长检查的时间，来给用户更多的时间试用。所以如果我们发现了bug，请报告，如果工作的话你好，告诉我们。反馈可以发送到openCollabNet论坛，或者是tigris.org的Subversion用户邮件列表。
为了得到Subversion的二进制程序，你可以使用新的Subversion1.5的图形化合并客户端（基于Subclipse），我们也有TortoiseSVN和其他工具的1.5版本的链接，如果你可以尝试这些工具并给我们和开发者你的反馈。
About the Author
Mark Phippard is Director Subversion Engineering at CollabNet. He leads the CollabNet Subversion team and is a project owner of the Subclipse project as well as a full committer for Subversion.
原始链接：http://blogs.open.collab.net/svn/2008/04/subversion-15-r.html
Filed Under (General) by rocksun on 20-04-2008
CollabNet主持了Visual Studio的插件AnkhSVN的开发，一些目标促使AnkhSVN 社区成长和加速插件的开发。作为开始，我们建立了AnkhSVN的路线图。 Subversion1.5的兼容性是众多路线的首要问题，包括良好的合并支持。为了正确的支持Subversion 1.5，我们需要更新我们的内部C#绑定（NSvn），或采用Subversion 1.5的.NET绑定SharpSvn,。我们选择了SharpSvn，为什么如此呢？让我们介绍一下SharpSvn。
Bert Huijben开始的SharpSvn项目，也是AnkhSVN的提交者。SharpSvn的目标不仅仅是一套Subversion的API，而是成为符合微软公共语言规范的语言抽象，结果是SharpSvn成为了.NET 2.0或更新.NET程序的Subversion客户端的绑定。（注意：因为Subversion 1.5和SharpSvn的最终API还没有确定，在最终版本发布之前，SharpSvn的API还可能改变。）
为了显示SharpSvn给.NET的Subversion应用带来的的价值，我创建了一个使用SharpSvn的简单程序。
当你下载并且查看源代码，你会看到大多数代码关于UI和线程，我只是用了很少的SharpSvn类。
这里是SharpSvn例子代码的主要部分：
/// <summary>/// Retrieves the Subversion log entries and potentially updates the/// DataGridView in a streaming fashion./// </summary>
private void retrieveAndRenderLog()
{ ….. // The Subversion target to run log against SvnTarget target; // Attempt to create an SvnTarget by parsing the targetPath if (string.IsNullOrEmpty(targetPath) || !SvnTarget.TryParse(targetPath, out target)) { ….. // SvnClient is disposable, using makes sure it’s disposed every time using (SvnClient client = new SvnClient()) { // Bind the SharpSvn UI to our client for SSL certificate and credentials SharpSvn.UI.SharpSvnUI.Bind(client, this); try { // Run the log subcommand client.Log(target, delegate(object lSender, SvnLogEventArgs le) { ….. // Iterate over each changed path for each log entry foreach (SvnChangeItem path in le.ChangedPaths) { tooltip.AppendLine(""); tooltip.Append(path.Action + " " + path.Path); if (path.CopyFromRevision != -1) tooltip.Append(" (" + path.CopyFromPath + "[" + path.CopyFromRevision + "])"); } …..
当用来编写.NET的Subversion应用时，SharpSvn是非常易于操作的API，可以简单的指出完成某些任务所需的类和API，文档和帮助在#ankhsvn （irc.freenode.net的AnkhSVN频道），允许我们在一个小时内完成例子程序。你也应该很高兴SharpSvn减轻了在使用语言绑定时手工维护认证callback、baton对象以及aprpool等低级对象的需要，。
SharpSvn的客户端API是与Subversion 1.5的同步API，也是未来AnkhSVN 2.0版本的核心。代码质量和完成度给人印象深刻，如果你希望采用SharpSvn开发，可以访问openCollabNet的本项目。
About the Author
Jeremy Whitlock is a sofware developer in CollabNet’s Subversion Engineering team. He is also an open source advocate who contributes to many projects. Jeremy loves playing video games and still continues to be amazed at the personal growth of his three year old son.
http://privacyreel.info/index.php?q=uggc%3A%2F%2Foybtf.bcra.pbyyno.arg%2Ffia%2F2008%2F04%2Ffunecfia-oevatf.ugzy
原始网站被屏蔽，很遗憾不能访问。
Filed Under (Subversion Client) by rocksun on 02-04-2008
对于很多人来说，Subversion1.5 被宣传为“合并跟踪还有其他”，也确实如此，花费在合并跟踪特性上的力量远大于其他领域，当然，Subversion 1.5不仅仅是合并跟踪这一项功能，也有一些其他的特性。Subversion社区为解决无数的bug话费了一年半的时间，但是现在我要讲的是一个半bug，半特性，或许会被你忽略的一个功能：从远程版本库合并。
Subversion现在允许你 — 部分的，近似的 – 允许你将版本库合并到另一个版本库的工作拷贝，因为Subversion模型的合并就是区别（diff）的应用，你也许会希望不应考虑diff的源，但是这是一个没有人讨论的特性，Subversion的public API 没有提及此事，Subversion book也没有涉及，Subversion的发布说明也没有吹嘘此时。实际上，我是在修改Subversion合并跟踪特性时注意到代码的注释，为何要隐藏这个秘密？当然，也许这只是一个意外的特性 — 并没有刻意去实现，但是却完成了。亦或许原因是这个特性仅仅有时候有效，无论怎样，从另一个版本库合并实际上是一个隐藏特性。
Apparently empowered by the spirit of "by golly this ought to work", one openCollabNet community member found this feature, though and found its shortcomings. User "argeman" posted the following to the merge-tracking beta program forums:
显然，在“by golly this ought to work”精神的鼓舞下，一个openCollabNet 成员发现了这个特性，也发现了其缺陷，用户“argeman”在合并跟踪beta程序论坛发布了这些内容：
我测试了svn 1.5 aopha2（转化了一些版本库然后使用了一下），它工作良好，唯一还没有工作的事情是（它不能在以前的subversion版本上工作），如果我尝试从另一个版本库合并时，无法正常添加文件。
我确实没有从另一个版本库上进行合并，但我立刻认识到了这个特性的价值，我可以用两个词来总结：“卖主分支（Vendor branches）”，卖主分支通常用来在不断变化中保存其他人的代码中的自定义修改，有很多方法可以实现，例如，你可以使用独立的分支，是某个卖主发布包的镜像，而另一个分支包含了你的软件中正在使用的包含你自定义修改的卖主包，你通过将纯卖主发布的区别应用到你的自定义拷贝实现升级。或者，你可以在你的版本控制分支中只包括卖主包的自定义拷贝，使用diff生成未版本化卖主包数据的差别，一些受虐狂比买你版本控制集成的力量，而喜欢维护自定义补丁文件，用来更新卖主包。（如果你是这样的人，一些人可以帮助你治疗）
从外部Subversion版本库合并的能力，提供了前面说的第一种和第二种方法的混合方法，在这个方法里，你只是维护自定义的卖主包拷贝，而不会去跟踪卖主发布的镜像（因为纯版本可以通过卖主的Subversion版本库获得），但是你现在要做的就是将这些纯版本的区别应用到你的自定义拷贝，而不是从乱糟糟的补丁文件中应用。
很不幸，“argeman”没有说“嗨，我发现了这个特性，并且它工作的很好”，这个帖子说明有这样一个潜在的特性，但是却不能够处理合并中要添加的文件，现在是享受开源软件的快乐的时候了，我花了大约40分钟修改了Subversion的代码，并进行了回归测试，并做了一些后续的相关修改，所以Subversion 1.5中，希望从外部版本库合并与内部合并会有一样的效果。合并源中的重命名依然会与Subversion一样，当从外部版本库合并时合并跟踪逻辑会被绕过，但合并在大多数情形下都会成功完成。
About the Author
C. Michael (Mike) Pilato has been on the Subversion project as a committer since 2000. Mike is one of the co-authors of “Version Control with Subversion” and he is on the board of the non-profit Subversion Corporation.
原文链接：http://privacysurf.info/index.php?q=uggc%3A%2F%2Foybtf.bcra.pbyyno.arg%2Ffia%2F2008%2F03%2Fqb-abg-cbfg-zre.ugzy
因为那个网站被GFW屏蔽了，所以请使用其它方式访问吧。
