有人使用Accurev进行源代码管理吗？我们(最终)从StarTeam切换到Accurev。

我的最初印象是严重缺乏GUI工具，但是底层引擎以及作为流的分支的概念令人难以置信。

我们面临的最大困难是评估与starteam交互的自己的DIY工具，或者用DIY新工具替换它们，或者找到并购买合适的替代品。

此外，是否有人使用AccuWork组件进行问题管理？ Starteam有一个非常不错的变更请求系统，而AccuWork几乎无法匹配它。我们正在评估是使用Accuwork，还是购买JIRA等第三方套件。

意见？

解决方案

回答

在以前的雇主中，我们审查了Accurev和Plastic SCM。归根结底，我对Accurev的界面或者所谓的"视频流"印象不深。我们和塑料一起去了，没人抱怨。

@乔纳森
这些流很有趣，但是我看不到当两个人触摸同一文件中的相同代码时，任何版本控制都如何神奇地避免冲突。 Accurev的模型很吸引人，但最终，干净整洁的分支和易于操作的易于合并的界面使Plastic成为我们的选择。 Plastic的时间轴视图(我忘记了实际名称)显示了分支/合并/签入的历史记录，因此从鸟瞰图查看项目的历史记录非常简单。

回答

@史蒂夫斯

接口很糟糕...但是流模型非常创新。

能够为主干流之外的新项目创建流，并让5个开发人员在其上工作，并且在将流合并回主干时没有任何形式的合并冲突是闻所未闻的。 Accurev。

回答

我在上一份工作中使用了AccuRev，但没有任何问题，但我非常喜欢Subversion(即使没有比较价格差异)。我记得客户端GUI也很慢。另外，我确实记得GUI只是调用了它们的命令行实用程序来与存储库接口。因此，将这些接口用于DIY工具可能并不难。

回答

我们已经使用AccuRev几年了。这是对我们上一个工具(Razor)的一项重大改进，尽管我建议其他人使用它，但确实有一些缺点。

好处：

• 基于流的界面非常直观。我每两周制作一次快照，并从快照中分支出许多正在进行的开发流。
• 在流之间移动更改非常容易，只需选择更改，将其发送到"更改面板"，然后选择目标流即可。它指导我们完成所有需要合并的文件。
• 命令行实用程序很棒。我们已经设法编写了围绕它的大多数发行版本的脚本。
• Visual Studio，Bugzilla等的集成...

缺点：

• 正如monjardin所指出的，客户端GUI可能很慢。我使用Windows版本进行所有历史记录/流搜索，因为它比X11快得多。当然，GUI是用Java编写的，因此性能显然不是他们的头等大事。
• 对于大型数据库(我说的是超过300,000个LOC)，它的运行速度开始变慢，尽管他们显然已在今天的4.7版本中解决了该问题。

我们选择了使用更便宜的许可证，但没有获得变更包功能(我看不到它们无论如何都不能很好地工作，因为促进单个变更的整个想法在持续集成的情况下就没有了)。到目前为止，还没有伤害我们。

总体而言，我们所支付的价格是一个不错的工具。在试用期间，我们评估了ClearCase，MKS，Spectrum和Subversion。 Subversion可能是一个不错的选择，但是在我们评估时它仍然是绿色的。我以前从未听说过Plastic，但很遗憾没有评估Perforce。

另外，据我了解，Trolltech(Qt的制造商)的工程师最近已改用git。我也有兴趣检查一下。

回答

好吧，我只能说我完全同意。后端很棒，但是UI很烂。流功能之所以出色，是因为它不会合并，因为来自父流的所有更改都将自动传播到所有子级，因此无需进行合并。我写了一篇有关Accurev UI的帖子，解释了我过去两年遇到的大多数缺点。

回答

Accurev很烂！团队生产力的代价过于复杂。
我曾与多个SCM合作，accurev的想法很棒，但不切实际。它是Merge Hell，其层次结构在UI中看起来不错，但在现实生活中很难处理。
特别是当我们重构代码时(有些人实际上会偶尔执行某些操作)，而当一个已失效的文件没有完全升级时，我们会陷入混乱。甚至更糟的是，如果有人覆盖已失效的文件并创建一个具有相同名称的新文件.... etc

UI令人难以置信。老实说，我们认为后端的性能如何并不重要。我们仍将使用UI(我使用VS插件，它相当不错，但有时会冻结IDE，很好！)。

如果我们生活在80年代，并打算为日常使用使用命令行，那么我想我们可以避免使用UI。如果我们有集成构建服务器，那么我们当然只能选择使用命令行(我不知道MSbuild / ANT / NANT没有本地任务)。我刚刚听说他们正在与http://www.electric-cloud.com/做一些工作。对此一无所知。

Accurev是新的，因此与svn相比，在线资源很少，我们会发现数百人完成了大量的集成工作(例如jira)。

如果我们是经理。 Accurev使我们在观看流时感觉很好，因为只要我们不必处理它，它的外观就会很漂亮。

如果我们是开发人员，(初级开发人员不会在乎，他/她将按照我们要求他们做的任何事情来做)

如果我们是一名建筑师，需要进行大量的重构，重新解决建筑师的决断...等等，我们会发现Accurev是最坏敌人，四处走动是痛苦的。如果我们问我的话，非常抗敏捷。这不是流动的。

如果我们是一名构建工程师，我们会发现它是PAIN，它使所有开发人员都可以进入一个过程，如果我们使用accurev(例如，在准备发行时将他们的代码提升到约定的流)，则必须这样做。 ..

CRM应该让事情变得更容易...我现在还没有看到Accurev做到这一点。它还不够成熟，如果我们想成为先驱并为希望事情变得更好而奋斗。 。
否则，请不要重新发明轮子，而要通过更多的案例研究和应用来建立更完善的架构。因为很实际，accurev声称提供的与众不同的做法不值得，因为我们每天都要处理它的烦恼...

回答

最近，我在AccuRev上工作(并管理)超过一年，我的大部分印象都非常好。

我们将其与" Plastic SCM"，SVN和" ClearCase-UCM"(我们已经拥有并使用)一起进行了评估，并决定转售ClearCase和SVN(这两个不同组中都使用了)并购买AccuRev。

• 首先，与所有其他工具都绑定到的旧分支架构相比，流架构是一种更加牢固，简便和安全的SCM方法(是的，即使ClearCase的"流"最终也是分支的包装)。关于他们网站的差异，有很多文章，我们可以搜索并阅读该文章，以使其易于理解。 (请尝试此链接，也请尝试此链接)
• 时间安全的体系结构-我们无法从软件仓库(=存储库)数据库中删除任何内容。我看到了具有适当管理员权限就可以执行此操作的工具。在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上)。
• 还有更多...

当然也有缺点(哪种软件是完美的？)例如，我希望在签入过程中也看到文件<->问题关联，就像在ClearCase中一样，而不仅仅是"促销就像今天一样，但是恕我直言，他们确实很小。

因此，正如我们所了解的那样，如果我们读完所有内容，我就是AccuRev的忠实拥护者，并且强烈建议我们使用它。恕我直言，今天它是我们有机会使用的最好的SCM工具之一；现代，明智，轻松而强大。

回答

我一直是Accurev的老用户，最近又转到了使用Perforce的工作。我得告诉你，我希望我能把Accurev回来。我同意UI缓慢且有问题。

但是，那里有一些真正的AWESOME可视化工具。我不敢相信有人会看版本历史记录浏览器而不会坠入爱河！流浏览器是一个很好的简单工具，可用来了解开发组织中正在发生的事情。

另外，污垢易于管理。 Accurev实际上是我最喜欢的工具之一。

回答

老实说，我觉得我需要仔细检查一下是否使用了与这些喜欢Accurev的人相同的工具。我在以前的工作中使用Subversion并非常喜欢它。我们从来没有任何问题可言，当然价格是正确的。我对Accurev的最大问题是，似乎他们觉得出于不同的缘故需要有所不同。它使用完全不同的词汇来表达版本控制概念，即使使用了将近6个月，对我来说还是很陌生。它具有不少于8或者9种状态，任何给定文件都可以进入，而Subversion的状态数约为其1/2左右。 GUI糟糕且运行缓慢，而IDE集成插件则低于标准水平。我以为在某个时候我会"得到" Accurev，看看为什么它会好得多，但这还没有发生。我的建议是远离。

回答

我刚刚碰到了这一讨论，并认为我会与AccuRev分享我们的经验。

我们使用Serena的Dimensions SCM已有大约8年的历史。两年前，我们在整合印度开发团队和英国开发团队方面遇到了一个重大问题。显然，我们将无法满足当前系统的需求，因此我们着手评估许多选项。我将在本文"我们如何整合离岸开发团队"中讨论所有这些问题。

到目前为止，我们使用AccuRev的经验一直非常积极。

• 易于设置和管理。
• 用户能够非常快速地上手(对于印度开发团队来说尤其重要)
• 我们从未遇到过速度问题(事实上，这是我们的主要优势之一)
• 复制就像梦一样
• 我确实同意UI可能有点笨拙(尤其是Unix客户端)。我希望当我们更新到下个月的最新版本时会更好。

总而言之，这是我们做出的最佳决定和购买之一。

回答

我在目前的工作中度过的最美好的一天之一是，他们放弃了Accurev并搬到Subversion。 Accurev使用过于复杂的概念。像上面的评论者之一一样，在使用了多年之后，我仍然不了解工件可能处于的不同状态。看来，Accurev的最大资产是其白皮书和流可视化，这两者都对管理有吸引力但对开发人员无济于事。我将Subversion，Mercurial和Git用于各种项目，并且会比其他任何工具推荐这些工具。

回答

排序答案：
使用最新的SVN服务器和SmartSVN(社区版是免费的)作为客户端。
我们将无需支付任何费用，便可以获得所需的一切。

血腥细节：
顺便说一句，在检查期间强加变更管理规则的功能对于编写为SVN钩子来说是微不足道的。我们用了几个小时，用一百行(或者大约一百行)代码完成了它，效果非常好，而且从未中断过。它将SVN与Bugzilla集成在一起，并施加如下规则：

• 为了提交，我们必须输入一条消息
• 为了提交，我们必须输入处于"有效"提交状态的Bugzilla ID。 ...依此类推，我们可以为自己的内心建立自己的规则

Accurev对我来说似乎是市场软件……糟糕的GUI客户端……非常慢(我们必须升级硬件才能使其真正有效地工作)，当然……我们必须为此付费！是的，如果我们使用它，我希望我们不必在美国的某个地方和印度的某个地方之间复制服务器：)

Perforce更加强大，但是管理起来却并不容易。无论如何，与Accurev相比，它是一款出色的产品。

在编写21世纪的专业软件(通常是企业软件)时，VSS和类似的东西甚至都不应被视为"版本控制"系统。这就像在打字机上写报告;-)

如果我们知道自己(使用软件)在做什么，那么SVN将为我们提供强大而有效的解决方案。当今(至少)有两个强大而有效的修订控制系统(SVN / GIT)，证明使用专有解决方案的合理性空间很小；有些原因可能是"惯性"：我们拥有它，我们不在乎为此付费，并且我们没有任何重大问题-换句话说，它对我们有用。

我到处都使用SVN，当它不存在时，我正在使用CVS，在那之前……不，我不会告诉你我多大了；-)

希望这可以帮助...

再见。

回答

让我进入反Accurev阵营。我们最近搬到了它，真是太恐怖了。我们有许多相当大的项目，而Accurev似乎对于我们拥有的文件数量几乎无法使用。通过VPN，将其忘记。它需要永远更新，跨流管理无法以任何直观的方式进行，UI复杂而缓慢。

另外，在我们使用的许多工具中对该工具的支持都不存在或者实施不充分。

加上不断弹出的各种错误，我想说我们为通过开源软件(例如Subversion)做得更好的事情浪费了很多钱。我们仍然在某些项目中使用CVS，即使对于正常操作和工作流程它也要好得多，以至于我会选择Accurev来使用它。

回答

另一个对Accurev表示失望的人。每个简单的操作似乎变得如此可怕，复杂的隐式错误消息使我们无所适从，只能找到有关本不应该存在的概念的理论解释。

UI太慢且反应迟钝，使我们想掏空眼睛。

远离。

回答

Accurev只是我用过的最糟糕的工具。

Subversion非常好，尤其是从cvs迁移时。

回答

4个月后，我的负面看法完全没有改变。尽管Accurev具有一些非常好的概念，但至少对于我们而言，速度和复杂性远远超过了优势。除了常见的关于GUI的抱怨和许多功能的模糊性之外，绝对最烦人的错误之一就是我们仅需要更新工作空间就必须跳过几圈，而由于无法仅更新一个目录而使情况更加糟糕。 (或者目录树)。

典型的更新包括等待很长一段时间以告知我们有重叠。当然，不会告诉我们重叠是什么。因此，我们必须进行重叠搜索，再等待一段时间，再解决重叠问题，再进行一次更新，再等待一段时间，并希望这次可以正常工作。

我们的一些远程开发人员尽可能不频繁地进行更新，因为通过VPN进行更新的时间是荒谬的。当然，我们在许多产品中都有大量的源文件，如果我们重新组织一切，我们可能会提高性能。

但是，我们聘请了Accurev(付出了高昂的代价)并告诉我们如何进行所有设置。仍然很烂。除此之外，我们真的不必重新组织与源代码合作的方式以适应源代码控制系统。这是一种工具，而不是一种商业模式。

最后，我们一直在尝试由Accurev编写​​的IntelliJ Accurev插件。它的功能和其他功能一样差，并且尽管Accurev对修复插件反应非常快，但我们不是他们的质量检查小组，也没有注册成为Alpha测试站点(是的，那是越野车)。我们最终放弃了，编写了自己的实际有效的插件。

回答

我目前的客户使用Accurev进行SCM，并且在使用DVCS(如Git或者Mercurial)进行了一些项目之后，老实说，使用Accurev就像在车门上闭脸一样令人愉悦。

Mac和Linux的GUI非常慢。如果我们使用Accurev，则可能会忘记使用IntelliJ或者NetBeans IDE中的重构支持，除非我们打算编写自己的插件。

哦，是的...让我们不要忘记这个小栗子==>邪恶的孪生兄弟。

从积极的方面看，情况可能更糟……可能是Clearcase。