有没有人使用Accurev进行源代码管理？我们正在（最终）从StarTeam切换到Accurev。
我最初的印象是GUI工具严重缺乏，但底层引擎和分支作为流概念是令人难以置信的。
我们面临的最大困难是评估我们自己的与starteam接口的DIY工具，并用DIY新工具替换它们，或者找到并购买适当的替代品。
此外，是否有人使用AccuWork组件进行问题管理？ Starteam有一个非常好的变更请求系统，而AccuWork并没有接近匹配它。我们正在评估使用Accuwork，或购买第三方软件包，如JIRA。
评论
答案 0 :(得分：60)
上帝的甜蜜母亲是Accurev可怕的。 300k行代码？与数百万人一起尝试，数百名开发人员正在开展大量项目。
持续整合？当然，这是开发人员可以通过定期合并，比如perforce，git，mercurial或任何实际完成工作的无数其他工具来实现的，但它成为了选择开发者如何继续。对于建筑师，销售线索，建筑工程师或任何实际使用源控制切片和骰子的人来说，Accurev是可怕的。
我参加了“高级Accurev主题”演讲，而第一个花絮是一个大型shell命令，用于清除Accurev的客户端缓存/同步机制，以便在Accurev更新时进行更正静默失败以下拉应该更新的文件。
时间戳优化复选框？深重叠？只有一个后台进程的模态对话框？ （如果这些过程不是冰川的话，那就没关系了。）为了能够拉出组件和交叉合并，选择性配置的流的级联图形到位了吗？没有时间锁定，更新实际上不是原子的？！ （诚实的回答：再次更新）
每次我尝试在Accurev中做任何严重的事情时，我觉得我在HAL9000，Skynet和Speak＆amp; amp;拼写。在线上？我生命中还有四个小时。
为什么我在这里，抱怨Accurev？因为我的其他机器花了整整四个小时才尝试通过VPN更新10MB的文件。为什么？因为其他一些变化已经陷入困境，需要对元素进行某种灾难性的重新同步扫描。最糟糕的部分？所有这些文件都在同一台计算机上的工作区中。我们谈论几个小时只是为了获得最近更新的工作空间，我可以在流历史中放置正确的缺口。
一句话Accurev评论：避免
答案 1 :(得分：56)
老实说，我觉得我需要仔细检查一下，看看我是否使用了与这些喜欢Accurev的人一样的工具。我在以前的工作中使用过Subversion并且非常喜欢它。我们从来没有遇到任何问题，当然价格合适。我对Accurev的最大问题是，为了不同的缘故，他们似乎觉得需要有所不同。它使用完全不同的词汇来表达版本概念，即使使用它近6个月，对我来说也是非常陌生的。它具有不少于8或9个状态的任何给定文件，相比之下，Subversion的数量约为1/2。 GUI蹩脚而且速度慢，IDE集成插件低于标准。我曾经认为，在某些时候我会“得到”Accurev，看看为什么它会好得多，但这还没有发生。我的建议是远离。
答案 2 :(得分：30)
我已经使用了AccuRev九个月，我焦急地等待着我不再使用它的那一天。我的一行评论是：
这就像开发人员编写的源代码控制一样 书，但以前从未实际使用过它。
基本概念缺失或极其复杂。例如，我刚刚失去了8个小时的工作，因为没有好的方法可以在流中进行“还原”更改。你可以“清除”那笔交易 - 但事实证明它已经消失了，你就不能选择你真正想要的改变。
GUI缓慢，臃肿且不一致。警告是神秘的，例如“错误合并元素ID 1234556”。每个对话框都是模态的。正如一张海报所说，文件可以有9种状态 - 但更重要的是，您必须手动点击9个选项的列表框才能看到每个文件的设置。
溪流模型听起来是一个好主意，但是从父流“继承”更改的默认行为在实践中实际上是非常糟糕的。只要对真正使用过AccuRev的人说“Deep Overlap”这个词，看着他们不寒而栗，变得苍白，和/或晕倒。制作流非常容易，但实际上将它们与任何有意义的差异合并是神秘且不确定的。
没有人提到这一点，但管理文件和目录过滤器的整个“包含/排除”规则系统完全被破坏了。该系统位于外部交易系统中，因此无法恢复，跟踪历史记录或重现对实时源流的更改 - 例如，当Johnny Intern决定“核心”库时对整个开发团队没用。
我能说明Accurev受欢迎程度的唯一原因是它针对“演示管理”案例进行了优化。我们正在使用AccuRev进行认真的软件开发 - 数十个项目和更多开发人员。流和GUI 看起来很棒但几周之后使用清漆来揭示旧的，破坏的，机械土耳其式系统。
远离Accurev - 如果你想要现代和免费的东西，可以使用Git或Mercurial;如果你想要一些坚如磐石，支持良好但价格昂贵的东西，请使用Perforce。
编辑： 作为后记，这是UI中缺乏关注和普遍粗暴的众多例子之一：
默认差异查看器的编号为“一个一个” - 例如，如果文件中有两个差异 - 查看器显示差异“0 of 1”和差异“1 of 1”。我的意思是，你真的觉得将代码信任给一个体现出如此愚蠢且易于修复的bug的系统。
答案 3 :(得分：16)
我现在的客户使用Accurev进行SCM，在使用像Git或Mercurial这样的DVCS的一些项目之后，我可以诚实地说使用Accurev就像在车门上关闭你的脸一样愉快。
Mac和Linux的GUI非常糟糕。如果您使用Accurev，则可以忘记在IntelliJ或NetBeans IDE中使用重构支持...除非您要编写自己的插件。
哦，是的......让我们不要忘记这个小栗子==＆gt;邪恶双胞胎。
从积极的方面来说，情况可能会更糟......它可能是Clearcase。
答案 4 :(得分：16)
我最近在AccuRev工作了一年多（并且管理过），我的大部分印象非常好。
我们与“Plastic SCM”，SVN和“ClearCase-UCM”（我们已经拥有和使用过）一起评估它，并决定转储ClearCase和SVN（两者都用于两个不同的组）并购买AccuRev。
首先，流架构比所有其他工具所依赖的旧分支架构更加稳定，简单且安全 SCM方法（是甚至ClearCase的“流”最终也是分支的包装者。有很多关于他们网站差异的文章，你可以搜索和阅读它以使其易于理解。 （尝试this link和this one too）
时间安全体系结构 - 您无法从depots（= repositories）数据库中删除任何内容。我看到了使用适当的管理权限可以执行此操作的工具。在AccuRev中，您将使用内部命令来更改或修复您所犯的错误，而这些错误又会被记录为新的交易。非常聪明非常安全。
集成！ AccuRev集成了许多工具（为您提供ALM捆绑） - 错误跟踪工具（如JIRA，ClearQuest），IDE，测试工具（质量中心），以及你找不到自己编写的（他们提供Java / Perl / XML / CLI SDK）
更改软件包，我不了解您，但我无法忍受不提供变更管理的SCM工具（有人说SVN吗？），如ClearCase“活动“和AccuRev的”问题“。这是我的意见，也是我的CM“最佳实践”之一。它们也可以与您的错误跟踪工具集成，因此您的用户可以处理真正的任务，例如功能和缺陷。
支持非常棒。作为IBM的前客户（因为Rational ClearCase现在是IBM的一部分），转向AccuRev简直太棒了。在评估期间，他们提供了大量的在线支持，以了解我们希望该工具如何为我们行事，因此我们甚至在我们支付一分钱之前就将它们调整到一起。在评估期之后，他们也保持了这种程度的回应;我们在从4.5.4升级到4.6期间遇到了一些问题，在短短的几个小时内（升级仍在进行中），支持人员联系了我，提出了一些提示，连接到我的桌面并最终修复了问题在任何其他公司的支持甚至开始试图弄清楚你是谁之前。当然，如果你选择开源工具而不是你自己！ 该工具还附带帮助系统，有时甚至可能过于冗长。并且不要忘记那些非常善于提供快速答案的论坛（尤其是cmcrossroads）。
还有更多......
当然也有缺点（哪种软件很完美？） - 例如，我希望看到文件＆lt; - ＆gt;办理登机手续时的问题，如同在ClearCase中，不仅仅是像今天这样的“促销” - 但恕我直言，他们真的很小。
所以，你可以理解，如果你读完了，我是AccuRev的忠实粉丝，我非常推荐它。恕我直言，它是今天你有机会参与的最好的SCM工具之一;现代，聪明，容易和坚强。
答案 5 :(得分：14)
Accurev很糟糕！它对于团队的生产力价格而言过于复杂。 我曾与几个SCM合作，并且accurev的想法很棒但不实用。它的Merge Hell具有在UI中看起来很好的层次结构，但在涉及现实生活时却很难处理。 特别是当你重构你的代码时（某些人实际上偶尔会做的事情）并且当一个已经失效的文件没有被提升时，你会陷入混乱。或者更糟糕的是，如果其他人覆盖了一个已解散的文件并创建了一个同名的新文件......等等
用户界面令人难以置信。老实说，你认为后端有多好，这无关紧要。你仍然会使用UI（我使用VS插件，虽然它有时会冻结IDE，但是很好啊！）。如果你住在80年代并且正在计划使用命令行进行日常使用，那么我想你可以避免使用UI。如果你有一个集成构建服务器，那么你当然别无选择，只能使用命令行（我知道没有MSbuild / ANT / NANT的本机任务）。我刚刚听说他们正在与http://www.electric-cloud.com/做一些工作。什么都不知道呢。
Accurev是新的，因此在线提供的资源很少，与svn相关，你会发现大量的集成工作由数百人完成（例如jira）。
如果您是经理。 Accurev会让你对溪流感觉很好，因为它看起来很漂亮，只要你没有处理它..
如果您是开发人员，（初级开发人员不会太在意，他/她会做您要求他们做的任何事情）
如果你是一名建筑师，重构很多，重新解决建筑规划......等等你会发现accurev是你的精神敌人，移动的东西就是痛苦。如果你问我，非常反敏捷。这不是流动的..
如果你是一名构建工程师，你会发现PAIN让所有的开发人员都参与到一个程序中，如果你使用accurev，你将不得不这样做（例如，在发布的预备中将他们的代码提升到商定的流程中）......
CRM应该让事情变得更容易......我在这一点上看不到Accurev这样做......它仍然不够成熟，如果你想成为先锋并且希望事情变得更好......为了它.. 否则，不要重新发明轮子，并采用更多的案例研究和应用程序。因为实际上，当你每天处理它的痛苦时，accurev声称提供的不同是不值得的......答案 6 :(得分：14)
我们几年来一直在使用AccuRev。它比我们的上一个工具（Razor）有了很大的改进，虽然我推荐它用于其他工具 - 它确实有一些缺点。
优点：
缺点：
我们选择使用更便宜的许可证并且没有获得更改包功能（我无法看到它们正常工作，因为促进个别更改的整个想法在持续集成的情况下飞行）。到目前为止，它并没有伤害我们。
总的来说，你支付的价格是一个很好的工具。我们在试用期间评估了ClearCase，MKS，Spectrum和Subversion。颠覆可能是一个不错的选择，但在我们评估时它仍然很绿。我以前从未听说过塑料，但我很遗憾没有评估Perforce。
另外，据我所知，奇趣科技（Qt的制造商）的工程师最近转向使用git。我也有兴趣检查一下。
答案 7 :(得分：12)
我一直是Accurev的长期用户，并且最近搬到了我正在使用Perforce的工作。我得告诉你，我希望我有Accurev回来。我同意 - 用户界面很慢而且有问题。
然而，那里有一些真正的AWESOME可视化工具。我无法相信任何人都会看到版本历史浏览器而不会坠入爱河！流浏览器是一个非常简单的工具，可以帮助您了解开发组织中正在发生的事情。
此外，污垢易于管理。 Accurev实际上是我最喜欢的工具之一。
答案 8 :(得分：12)
我们已经使用AccuRev 4年了。我非常讨厌它，主要是因为其可怕的GUI。几年前，AccuRev为他们的客户发送了一份调查报告，在调查结束时，有一个提出建议的领域。我开始收集最让我烦恼的东西，下面你会发现我现在拥有的东西。不幸的是，它充满了AccuRev术语，但我认为你无论如何都会得到这个想法。
<小时/>
在检查历史记录时，开发人员通常希望看到上一个事务/版本的差异。这应该像双击一样可访问。例如，双击事务日志中的文件可以打开diff到以前的版本。双击默认组过滤器中的文件可以打开差异备份，双击文件在修改搜索可以打开差异到最近。这将节省大量时间。
常见的经验是，开发人员很少从AccuRev中打开文件进行编辑。相反，他们经常差异文件，然后还原或促进变化。所以双击不应该打开文件进行编辑，它应该改为对它们进行区分。这可能是首选项中的一个选项，因此不同的人可能会决定是否要双击来区分文件或打开文件。
应该可以在流或工作空间历史记录中选择两个事务，并在它们之间执行文件差异。
合并流中的重叠需要执行＆＃34; Deep Overlap＆＃34;在工作区中搜索比搜索特定流中的重叠花费更多时间。然后需要按重叠流对重叠进行排序，并仅合并来自特定流的重叠。应该有更方便的方法在流中执行合并重叠。例如，能够限制特定流的深度重叠搜索，并且不显示父流中的重叠。如果您在此时间锁定的流下有多个流，或者根本没有时间锁，则时间锁定流限制深度重叠搜索不是很有用。
现在有一种简化的方法涉及创建更改调色板，但它仍然不方便。如果该流下的工作空间可用于重叠合并，则应在流级别提供合并菜单项。
注释工具非常尴尬：
上下文菜单项＆＃34;添加到流过滤器＆＃34;在引入新流收藏时删除了应该可以右键单击流并将其添加到其中一个流收藏夹（第二级上下文菜单，或者可能会弹出对话框）。现在编辑流收藏夹非常烦人，特别是当您需要有两组相似的流时。
将流名称复制到剪贴板应该很容易。现在你需要打开＆＃34;改变流＆＃34;对话框。流浏览器中的Ctrl + C可以将所选流的名称复制到剪贴板。 无法从流视图中复制流名称。右键单击选项卡可以在剪贴板中复制流名称，或者显示上下文菜单，其中＆＃34;将流名称复制到剪贴板＆＃34;其中的项目。
仅显示第一个不同的字符，而不是整行差异，不突出显示语法。幸运的是，diff工具可以很容易地切换到外部工具，所以这很小。
在过去3年中，AccuRev在此列表中添加了3件事（我已将其删除，因为它们已经实施）：
除了GUI之外，AccuRev在整体上存在根本性缺陷：
您无法轻易向后更新。有accurev update -t <transaction-number>命令，但如果您更新到事务100，则无法使用accurev update -t 95更新到事务95。为此，您需要在备份流上设置时间锁定（这将在AccuRev中引入事务）并更新您的工作区。
更新时，您可能会在没有任何通知的情况下发生无效的来源状态。这是因为Overlaps功能。重叠基本上是冲突（当你和他们改变文件时）。如果工作区中存在重叠，则在允许更新之前，您需要将其合并。但是，如果您在工作区中有重叠，那么您就不会注意到这一点，但重叠的文件不会在您的工作区中更新。考虑以下流结构
[Depot Root] <- [Team stream] <- [Your stream] <- [Your workspace]
我们假设您更改了foo.cpp并将其提升为[Your stream]。之后，您的团队中的某位人员同时更改了foo.h和foo.cpp，请让我们为课程Foo添加方法，并将文件提升为[Team stream]。更新工作区后，您将获得foo.h的新版本（因为您没有对其进行更改），但您未获得foo.cpp 因为它在[Your stream]中重叠。因此，您的更新将变得干净，但如果您在此之后尝试构建，则链接器会抱怨未解析的符号Foo::NewMethod。
答案 9 :(得分：12)
我目前工作中度过的最美好的一天是他们放弃Accurev并转向Subversion的那一天。 Accurev使用过于复杂的概念。就像上面的一位评论者一样，在使用它多年之后，我仍然不了解文物可能存在的不同状态。看来Accurev最大的资产是它的白皮书和流可视化，这两者都对管理有吸引力但对开发者没有任何作用我将Subversion，Mercurial和Git用于各种项目，并推荐使用这些工具。
答案 10 :(得分：11)
Accurev是反敏捷工具：
Accurev的主要思想是为不同的团队使用不同的流，因此，team1所做的更改不会影响team2。
听起来不错，但在现实世界中我们都知道最后我们必须合并来自两个团队的代码并相信我在Accurev中的噩梦。两个团队在他们的流中所做的变化越多，每个人在最后合并所花费的时间就越多。
如果每个团队使用SVN在单独的分支中进行开发并尝试在开发1个月后合并所有内容....基本上Accurev会创建较晚的合并价格，如果您选择Accurev超过1个团队，您将支付此价格。
为了解决第1点创建的问题，人们决定拒绝跨功能团队，而不是功能性团队。他们甚至提供支持这一观点的论据，如“知识专长”原则。
换句话说，当你没有跨职能团队（以及敏捷团队）时，让特定部分的专家更容易系统，因此他们将更好地执行代码审查，并充当“信息/设计/实施专家”。
我们都知道信息专家不仅在敏捷方面是一种反模式，因为它更好传播专业知识，以避免发展中的知识瓶颈。
答案 11 :(得分：8)
让我参加反Accurev训练营。我们最近搬到了它，这太可怕了。我们有很多相当大的项目，而Accurev似乎几乎无法用于我们拥有的文件数量。通过VPN，忘了它。更新需要永远，跨流管理不能以任何直观的方式工作，UI复杂而缓慢。
此外，我们使用的许多工具对它的支持要么不存在，要么执行不力。
添加不断出现的各种错误，我认为我们浪费了大量资金，因为开源软件（例如Subversion）可以做得更好。我们仍然在某些项目中使用CVS，即使它对于正常操作和工作流程来说也要好得多，我会通过Accurev选择它。
答案 12 :(得分：8)
Accurev的另一个大拇指。每一个简单的操作似乎都变得非常复杂 - 神秘的错误信息会让你分散到手册，只能找到关于不应该存在的概念的理论解释。
用户界面非常缓慢且反应迟钝，这让你想要掏出眼睛。
远离。
答案 13 :(得分：8)
Accurev有一些很棒的概念;但遭受以下困难：
1）命令行界面中存在许多不一致之处
2）应用程序/界面中存在许多错误和麻烦。例如。由于存在影响快照和传递流的若干错误，它们的时间安全属性实际上并不是时间安全的
3）重要特征中的主要缺陷......如上所述;时间安全的错误;因问题合并的错误。
3）他们应该落后一年，因为他们浪费了整整一年的时间来试图将他们的后端移动到数据库 - 这将是版本5，可能永远不会看到光明的一天。
4）营销很好;但该产品并不辜负营销炒作
5）每个版本都有重大的关键错误，要求他们发布即时修补程序。这对我们来说是一个重大的破坏。这些都不是小问题
6）不能很好地扩展......占用大量的磁盘空间并随着时间的推移而变慢
说完了这一切;它仍然是一个好产品;但是，如果我再次这样做，我会考虑使用git。
答案 14 :(得分：6)
4个月后，我非常消极的看法根本没有改变。虽然Accurev有一些非常好的概念，但速度和复杂性远远超过优势，至少对我们而言。除了关于GUI的常见抱怨和许多功能的默默无闻之外，最令人讨厌的错误之一是你必须跳过多少箍来更新工作空间，由于无法只更新一个目录而变得更糟糕（或目录树）。
典型的更新包括等待一段时间被告知你有重叠。当然，你不会被告知重叠是什么。所以，你必须进行重叠搜索，等待另一个漫长的时间，解决重叠，进行另一次更新，等待一段时间，并希望这次工作正常。
我们的一些远程开发人员尽可能不经常更新，因为VPN上的更新时间很荒谬。当然，我们在许多产品中都有大量的源文件，如果我们重组了所有内容，我们可能会提高性能。
然而，我们聘请了Accurev（费用很高）进来告诉我们如何设置一切。仍然糟透了。除此之外，我们真的不应该重新组织我们使用源代码来适应源代码控制系统的方式。这是一种工具，而不是商业模式。
最后，我们一直在试用由Accurev编写的IntelliJ的Accurev插件。它的效果和其他部分一样糟糕，虽然Accurev对修复插件非常敏感，但我们不是他们的QA组，我们也没有注册成为alpha测试站点（是的，它就是那个bug）。我们终于放弃并编写了我们自己的插件，它实际上有效。
答案 15 :(得分：5)
在之前的雇主，我们审查了Accurev和Plastic SCM。在一天结束时，我对Accurev的界面或所谓的“流”并没有留下深刻的印象。我们和Plastic一起去了，没有人抱怨。
@Jonathan 这些流很有趣，但是当两个人在同一个文件中触摸相同的代码时，我看不出任何版本控制如何能够神奇地避免冲突。 Accurev的模型非常吸引人，但在一天结束时，漂亮干净的分支和合并与简单易用的接口使得Plastic成为我们的选择。塑料的时间线视图（我忘记了实际名称），显示了分支/合并/登记历史记录，从鸟瞰图中查看项目历史非常简单。
答案 16 :(得分：5)
我的公司从2010年初开始使用Accurev，之前是StarTeam，而在很久以前就是CVS。我还没有使用过CVS（当时我在一个不同的团队中），所以我没有在那里进行任何比较，而且我从不打算过于亲密地学习StarTeam。
从那时起，我在空闲时间也玩过SVN，Git和Mercurial（Hg）的CLI和Tortoise版本。我计划在某些时候让Git更彻底，但我发现Hg更直观和容易（至少在Windows下）。无论如何，就像我说管理层用Accurev背负着我们，花了很多时间熟悉它（GUI和CLI两者）作为开发人员......我绝对讨厌它。
在线程的前面有人将其总结为开发人员编写的软件，这些软件在书中读过SCM但从未使用过它......我全心全意地同意，但你也觉得他们有相同的经验水平使用GUI，高效处理等（事实上，我看到Accurev有一个名为＆＃34; Kando＆＃34;基于Git的新产品......听起来他们终于意识到他们的模型有多糟糕。但引用一位同事的话，我不会相信同一团队在这一点上所写的任何东西＆＃34; ......我不得不怀疑是否有一个婴儿擦拭产品名为＆ ＃34; Kandoo＆＃34; ...）
好的，显然我不在乎产品。如果你花时间阅读这个帖子，那么显然有很多人对它有类似的看法。但是我想分享一下我过去几年里对它的一些抱怨 - 顺便说一句，如果它对任何人都有帮助，我想我们之前使用的是v4.7而且已经在v5.3上了（？）现在已经有一段时间了。
我与Accurev最大的优势在于它是多么缓慢和低效。请注意，我没有使用GUI这个词 - 我已经尝试过GUI和CLI--缓慢的部分都在服务器上，所以你不管怎样都搞砸了。好像我每次都看到其中一个该死的模态对话框/状态栏...我切换标签 - bam！：处理，请稍候。我重新说了一句 - 哦等一下。对于＆＃34;更新＆＃34;我希望它有点慢（虽然有时当它尖叫时会变得很烦恼＃34; Overlap＆＃34; [又称冲突]当我碰巧有一个带有IDENTICAL内容的文件时它正在推动它下）。我将目录浏览更改为路径...处理，处理，＆＃34;哦，你想再下一个子文件夹＆＃34; ...让我再处理一下。你明白了。
这是我唯一的牛肉吗？一定不行。
1）对于合并工具，我已经忽略了空白＆＃34;选项检查了多年，但我只能记得它工作一次（例如，我们说的是关于比较说2个版本的JSP，我将空格转换为制表符或修剪一些尾随的空格或其他东西） 。为什么这是一个问题？因为对于历史上看起来并希望看到真正改变的所有其他开发者而言，它变成了纯粹的折磨。如果他们无法正确实施，请不要在那里放置F *** ING选项。 （注意：使用WinMerge作为外部比较工具，使用适当的设置可以正常工作）
2）我曾经有过将文件检入一个流然后需要将同一个文件的IDENTICAL副本放入另一个流（使用相同的问题＃）的实例，这会导致它发脾气。如果我使用错误的问题＃，它没有问题。这可能是一个孤立的案例（可能是由于我公司背负的其他糟糕的流程决策）但我认为我提到它是完整的。
3）历史？全部存储在服务器上。翻译：如果您喜欢等待它切换标签，创建/重新显示工作区，然后更新，那么当您想要查看历史记录时，您可以进行更多相同的操作。 4）它的排除规则的实施方式不仅可怕而且可悲。在Windows下，您实际上必须创建一个环境变量，您可以在其中为您不想显示的文件创建一些排除项。它不支持REGEX。我已经看到其他几个SCM提供了更好的方法（我喜欢Hg中使用的忽略文件。我认为在Git中也有类似的东西） - 不仅是正则表达式和glob模式支持，但在FILE中定义它更加系统友好，更容易编辑，将其放入环境变量。不仅如此，似乎忽略过滤器充其量也是如此。我们的项目定义方式有项目文件夹下的构建文件夹（由源代码控制），并试图排除构建文件夹下的所有文件夹似乎无法正常工作 - 大多数文件夹仍显示在我的＆＃34;外部＆ ＃34;即使在设置规则后也会过滤。5）它的签到过程（＆＃34;推广＆＃34;）似乎也以缓慢而低效的主题运行。我们使用外部票务系统（不是AccuWork ......我们的票务系统有其缺陷，但在使用AccuRev之后，我无法对该产品进行成像更好）。无论如何，当我们说'＃34;推广[这个文件]＆＃34;时，首先它会弹出另一个模态对话框（在所需的等待之后，它会进行更多的统计处理），然后它会显示所有门票的列表拉了（有很多......太多了，无法可靠地找到任何东西）。接下来，我们必须从其他系统输入我们的票号，并等待一段时间才能找到匹配（我认为已经拉出了列表...... geez）。最后，它将显示匹配，然后我们选择一个并告诉它使用该票号进行推广。经过一段时间的等待，我们终于完成了。
我可以继续，但我会停在那里......这篇文章太长了。相反，让我以自己的方式总结Accurev：在我们试图快速解决问题的过程中，我不得不等待所有这些缓慢烦人的＆＃34; Stat处理＆＃34;等对话框后，我走了过来为他们提供一个新的口号：＆＃34; AccuRev：当秒数计算时，你的修复只需几分钟就可以了＃34;。
由于管理层没有摆脱Accurev（我知道他们在没有企业支持的情况下不会做任何事情，但我还是请求他们考虑其他事情：SmartGit ...... Kiln .. .Perforce ...），我一直在使用TortoiseHg本地版本控制我的文件（除了Accurev）。这是一个更多的工作。但对于那些背负着Accurev的人来说，它让生活变得如此简单。您将获得：更好的差异管理 - 在＆＃34; accurev update＆＃34;之后更容易查看和查看代码更改，能够查看某些历史记录而无需等待服务器10年，能够直接在您和您之间共享另一个开发人员（假设他们也安装了它），如果你在试图清除Accurev的合并地狱（＆＃34; Overlapped＆＃34;文件）时意外擦除了某些内容，则能够恢复/恢复你的更改，甚至更多，如果你能让你的团队的其他成员使用它。
编辑：忘记提及，在与我们的构建工程师进行转换时，我被告知虽然Accurev有一个可以开发的Java API，但显然需要购买某种额外的许可。我无法证实这一点，因为a）我无法在Accurev的网站上找到定价*和b）我怀疑他们在工作中告诉我......*有点奇怪，考虑到我可以很容易地找到Perforce，Kiln，StarTeam和SmartGit的某种粗略定价。当一些产品没有预先列出任何类型的价格时，我通常会有一种粗略的感觉，猜测它不会让我感到惊讶，因为Accurev属于那个类别......
答案 17 :(得分：5)
Accurev只是我用过的最糟糕的工具。
Subversion非常好，特别是如果你从cvs迁移。
答案 18 :(得分：5)
@Steveth
界面很糟糕......然而溪流模型非常具有创新性。
能够为中继流创建一个新项目的流，并且有5个开发人员正在处理它，并且当我们将该流合并回主干时没有任何形式的合并冲突是闻所未闻的，但它在Accurev中运作良好。
答案 19 :(得分：4)
排序答案： 使用最新的SVN服务器和SmartSVN（社区版免费）作为客户端。 你不会支付任何费用，你可以得到你需要的一切。
血淋淋的细节： BTW在检查期间强制执行更改管理规则的功能很简单，可以写为SVN挂钩。我们在几个小时内，在一百行（或左右）的代码中完成了它 - 它运行得非常好并且从未破坏过。它将SVN与Bugzilla集成在一起，并强制执行以下规则：
Accurev对我来说似乎是市场......糟糕的GUI客户端......非常慢（我们不得不升级硬件以使其真正有效地工作），当然......你必须付钱！是的，如果您使用它，我希望您不必在美国的某个地方和印度的某个地方复制您的服务器：）
Perforce更强大，但管理起来不是很容易。无论如何，与Accurev相比，它是一款优质产品。
在21世纪编写专业软件（通常是企业软件）时，VSS和类似的东西甚至不应被视为“版本控制”系统。这就像在打字机上写报告一样; - ）如果您知道自己在做什么（使用您的软件），那么SVN将是一个强大而有效的解决方案。目前存在（至少）两个强大而有效的版本控制系统（SVN / GIT），使用专有解决方案的合理性很小;一些原因可能是“惯性”：你拥有它，你不关心付钱，而且你没有任何重大问题 - 换句话说，它适合你。
我到处都使用SVN，当它不存在时我使用的是CVS，在此之前......不，我不会告诉你我多大了; - ）
希望这有助于......
侨。
答案 20 :(得分：4)
我曾经是SVN和Accurev管理员。 Accurev花了很长时间在我身上 - 大约六个月，但我现在喜欢它在公司企业环境中。这里有几点需要考虑。
<强>优点：
<强>缺点：
然而，就像任何复杂的工具一样，您的欣赏会增加您对它的理解和了解。
答案 21 :(得分：4)
嗯，我只能说完全同意。后端很棒但UI很糟糕。流功能很棒，因为它使合并变得不那么聪明，因为来自父流的所有更改都会自动传播到所有子节点。我写了a post about Accurev UI，解释了我过去两年遇到的大部分缺点。
答案 22 :(得分：3)
我在以前的工作中使用过AccuRev并且没有任何问题，但我更喜欢Subversion（即使没有比较价格差异）。我记得客户端GUI也很慢。此外，我记得GUI只是调用他们的命令行实用程序来与存储库进行交互。因此，将这些界面用于DIY工具可能不会那么难。
答案 23 :(得分：3)
我使用Accurev已有一年了。我不喜欢它。以下是我遇到的一些问题：
1.它的GUI非常糟糕：它很慢，每次我在标签（流和工作区）之间切换或执行某些操作时我都要等几秒钟。它有时会给你一个令人困惑的错误信息，无法帮助你找出错误的信息。
2.它有很多概念，你必须花很多时间学习Accurev本身。
3.我曾经遇到过这样的问题：我有一个由我们的构建过程修改的版本控制文件。后来，我的队友将该文件移动到他工作区的其他位置并推广了更改。当我运行“accurev update”时，它只是告诉我“某个文件已被移动”，一切看起来都很正常。但实际上命令在移动的文件处停止，不再更新其他文件。这很令人困惑 - 你的更新命令没有更新工作，但你不知道它。唯一输出的消息“某个文件已被移动”看起来就像其他详细输出一样。它没有告诉我我的更新失败或中止或其他。
在此之前我使用了SVN和ClearCase。 SVN是一个很棒的工具，简单易用。我对ClearCase的抱怨并不多。 Accurev真的很令人沮丧...
答案 24 :(得分：1)
我刚刚看到这个讨论，并认为我会与AccuRev分享我们的经验。
我们一直在使用Serena的Dimensions SCM大约8年。两年前，我们将印度开发团队与英国开发团队整合在一起，遇到了一个重大问题。很明显，我们无法用现有系统满足我们的需求，因此我们着手评估一些选项。我在本文How We Integrated Our Offshore Dev Team.
中讨论了所有这些到目前为止，我们使用AccuRev的经验非常积极。
总而言之，我会说这是我们做出的最好的决定和购买之一。
答案 25 :(得分：1)
注意：我是AccuRev用户，我非常喜欢它。我已经在这里提出了一些答案，并想补充一下：
我最近在Jez Humble和David Farley的书Continuous Delivery中偶然发现了AccuRev的这篇“评论”：
[第14章，第385页]
商业版本控制系统
（...）我们能够全心全意推荐的唯一商业VCS是：
- （...）
- AccuRev。提供类似ClearCase的功能，可以进行基于流的开发，而不会产生严重的管理开销和与ClearCase相关的糟糕性能。
- （...）
我可能会添加我从未使用过ClearCase，但我是AccuRev管理员，这确实很少管理。 （WRT表现，this question可能会提供更多见解。）