我的初始印象是GUI工具严重缺失,然而底层引擎和分支流概念令人难以置信。
我们面临的最大困难是评估与Starteam交互的自制工具,并用新的DIY工具替换它们,或者找到并购买适当的替代品。
此外,有人使用AccuWork组件进行问题管理吗? Starteam拥有非常好的更改请求系统,而AccuWork远远无法匹配。 我们正在评估使用Accuwork还是购买第三方软件包,例如JIRA。
意见?
天啊,Accurev真是太可怕了。代码量达到300k行?试着在数百位开发人员同时为许多项目工作时使用它吧。
持续集成?当然,开发人员可以通过定期合并代码文件(例如在Perforce、Git、Mercurial或其他许多实际起到作用的工具中)来近似实现,但对于架构师、技术领导、构建工程师或任何实际使用源代码控制工具来分析的人来说,Accurev简直太可怕了。
我参加过一次“高级Accurev主题”讲座,其中第一个提示就是一个大型shell命令,用于清除Accurev客户端缓存/同步机制,以纠正Accurev更新未能成功下载应该更新的文件的情况。
时间戳优化复选框?深度重叠?只有一个后台进程的模式对话框?(如果这些进程不是异常缓慢的话,那还好。)为了能够提取组件和交叉合并而放置的层叠图形配置流?更新没有实际上实现原子性,除非进行时间锁定? (诚实的回答:再次更新)
每次我试图在Accurev中进行任何严肃的工作时,我都感觉自己正在与HAL9000、Skynet和Speak & Spell一起玩俄罗斯轮盘。代价?再多花费四个小时的时间。
我为什么要在这里抱怨Accurev呢?因为我的另一台计算机花了整整四个小时才尝试通过VPN更新10MB的文件。原因是什么?因为出现了一些其他的变更导致需要进行某种灾难性的重新同步扫描元素。最糟糕的部分是,所有这些文件都在同一台计算机上的一个工作区中。我们谈论的是几个小时的时间才能使最近更新的工作区达到我可以将正确的刻度放入流历史记录的程度。
一个词的Accurev评论:避免使用
我已经使用AccuRev九个月了,期待着有一天不再使用它。我的评价是:
这就像是由只是在书上读过源代码控制的开发人员编写的,但实际上从未使用过。
基本概念缺失或非常复杂。例如,如果已经提交到流中的更改没有很好的“还原”方式,在这种情况下我的工作会丢失8个小时。您可以"清除"该事务 - 但那就是它消失了,您无法挑选您真正想要的更改。
GUI 缓慢、臃肿和不一致。警告信息难以理解,例如 "合并元素 ID 1234556 的错误"。每个对话框都是模态的。正如一个用户所说的那样,文件可以处于9种状态之一,但更重要的是,您必须手动单击9个选项列表,以查看每个文件的设置。
流模型听起来像是个好主意,但实际上从父流"继承"更改的默认行为在实践中非常糟糕。只需对任何真正使用过AccuRev的人说"深度重叠",看看他们是否发抖,脸色发白或晕倒。创建流非常容易,但实际上将它们与任何有意义的差异合并起来是深奥的和不确定的。
没有人提到这一点,但整个"包括/排除"规则管理文件和目录过滤器的系统完全失效了。此系统在事务系统之外,因此无法还原、跟踪历史记录或重现对实时源流的更改 - 例如,当Johnny Intern决定"核心"库对整个开发团队没有用处时。
我认为 Accurev 受欢迎的唯一原因是它针对“演示给管理层”的情况进行了优化。我们正在使用 AccuRev 进行严肃的软件开发 - 多个项目和更多的开发人员。流和 GUI 看起来很不错,但几周后会发现其机械、过时,就像一个老旧、破烂的系统。
如果你想要现代和免费的系统,请远离 Accurev,使用 Git 或 Mercurial。如果你需要可靠而昂贵的系统,请选择 Perforce。
编辑: 这里有一个缺乏关注和一般粗制滥造界面的许多例子之一:
默认的差异查看器编号存在“偏移一”的问题 - 例如,如果文件中有2个差异,则查看器显示差异“0 of 1”和差异“1 of 1”。我的意思是,真的相信一个展现如此愚蠢且易于修复 bug 的系统来处理你的代码吗?
我的目前的客户使用Accurev进行软件配置管理,经过几个使用类似Git或Mercurial的分布式版本控制系统(DVCS)的项目之后,我可以诚实地说,使用Accurev就像把自己的脸挤进了车门一样难以忍受。
在Mac和Linux上使用的GUI非常慢。如果你使用Accurev,就别指望在IntelliJ或NetBeans IDE中使用重构支持...除非你打算自己编写插件。
哦,对了......还有这个小毒瘤==>邪恶的孪生。
但是好在,情况可能会更糟糕......例如Clearcase。
最近我在使用和管理AccuRev超过一年,我的印象大多数都非常好。
我们在评估了“Plastic SCM”、“SVN”和我们已经拥有并使用的“ClearCase-UCM”之后,决定放弃ClearCase和SVN(两者分别在不同的组中使用),购买AccuRev。
首先,流式结构比其他所有工具都绑定的旧分支结构更为可靠、简单和安全。他们的网站上有很多关于差异的文章,您可以搜索并阅读以使其易于理解。(尝试这个链接和这个链接)
时光安全体系结构:您无法从存储库数据库中删除任何东西。我见过一些工具可以通过适当的管理员权限执行此操作。在AccuRev中,您将使用内部命令来更改或修复错误,并将记录为新的事务,非常聪明,非常安全。
集成!AccuRev与许多工具(为您提供ALM包)集成-缺陷跟踪工具(如JIRA,ClearQuest),IDE,测试工具(质量中心),如果找不到一个,您可以编写自己的(他们提供Java / Perl / XML / CLI SDK)。
更改软件包,我不知道您是否也是无法忍受那些没有提供变更管理(有人说SVN吗?)的SCM工具,例如ClearCase“活动”和AccuRev的“问题”。在我看来,这是必须的,并且是我的配置管理“最佳实践”之一。它们还可以与错误跟踪工具集成,因此您的用户可以处理真正的任务,如特性和缺陷。
支持非常出色。作为IBM的前客户(因为Rational ClearCase现在是IBM的一部分),转向AccuRev真是太棒了。在评估期间,他们提供了许多在线支持,以了解我们想要工具为我们提供的功能,因此我们甚至在支付一分钱之前就已经共同完善了它。在评估期过后,他们仍然保持了这种响应度;我们在从4.5.4升级到4.6时遇到了一些问题,在升级过程中几个小时内(而其他公司的支持人员甚至尚未开始尝试弄清您是谁时),支持人员联系了我,建议了一些提示,并连接到了我的桌面,最终解决了问题。当然,如果选择开源工具,那么您就只能自行解决问题!此外,该工具还带有帮助系统,有时可能过于详细。不要忘记论坛(尤其是在cmcrossroads上),也非常擅长提供快速回答。
当然还有其他很多......
当然,也存在缺点(哪个软件是完美的呢?) - 例如,我希望在提交检查中也能像ClearCase一样显示文件<->问题关联,而不仅限于“推广”,但在我看来这些都是非常小的缺点。
所以,如果你都看完了,你就能理解我是AccuRev的忠实粉丝,并强烈推荐使用它。在我看来,它是目前最好的软件配置管理工具之一,现代化、智能化、易于操作且功能强大。
Accurev很烂!它对于团队生产力的价格而言过于复杂。我曾经使用过多种软件配置管理工具(SCM), accurev的理念是伟大的,但在实际操作中并不实用。它在UI上显示得很好,但是当你在现实生活中处理时,它会成为一个痛苦的等级混乱的合并地狱。
特别是当您重构代码时(这确实是有些人偶尔会做的事情),如果某个无效文件未被完全推广,就会陷入麻烦。更糟糕的是,如果其他人覆盖了无效文件并创建了一个同名的新文件...等等
UI难以置信的糟糕。 诚然,无论您认为后端有多好,这都无关紧要。 您仍然会使用UI(我使用的是VS插件,还算可以,但有时会冻结IDE,很不错吧!)。
如果您生活在80年代并计划在日常使用中使用命令行,则可以避免使用UI。 如果您有整合构建服务器,那么您当然只能使用命令行(至少我不知道有针对MSbuild / ANT / NANT的原生任务)。 我只听说他们正在与http://www.electric-cloud.com/合作。 我仍然不知道任何信息。
Accurev是新的,因此在线上有少量可用资源,相对于svn而言,您将找到数百人完成的集成工作。
如果您是经理,则使用Accurev会让您看起来很不错,因为它看起来非常漂亮,只要您不必处理它。
如果您是开发人员(初级开发人员不会太在意,他/她会按照您的要求做),
如果您是架构师,经常进行重构,重新审视架构决策等,您会发现Accurev是您最大的敌人,移动文件很困难。 如果您问我,这是非常反敏捷的。 它不流畅。
如果你是一名构建工程师,你会发现使用Accurev非常痛苦,因为你需要让所有开发人员按照流程操作(例如:将他们的代码推广到预定发布流中)。...
CRM应该让事情变得更容易...但我不认为Accurev在这方面做得很好..它仍然不够成熟。如果你想要成为先驱并为未来的改进而奋斗,请继续使用它。 否则,不要重复造轮子,选择一个更成熟、有更多案例和应用的产品。因为实际上,当你每天处理它的困难时,Accurev所声称提供的那些区别并不值得。
当查看历史记录时,开发人员最常见的需求是查看与上一个事务/版本的差异。这应该像双击一样容易访问。例如,在事务日志中双击文件应打开与上一个版本的diff。在默认组筛选器中双击文件应打开到备份的diff,在修改搜索中双击文件应打开到最新版本的diff。这将节省大量时间。
通常开发人员很少从AccuRev内部打开文件进行编辑。相反,他们往往会对文件进行差异比较,然后还原或推广更改。因此,双击不应打开文件进行编辑,而应该将其作为diff进行比较。这可能是偏好设置中的选项,因此不同的人可以决定他们是否希望双击将文件进行diff还是打开文件。
应该可以在流或工作区历史记录中选择两个事务并执行文件差异比较。
在流中合并重叠需要在工作区执行“深度重叠”搜索,这比在特定流中搜索重叠需要更长的时间。然后需要按重叠流对重叠进行排序,并仅合并来自特定流的重叠。应该有更方便的方式在流中执行重叠合并。例如,限制特定流的深度重叠搜索并不显示父流中的重叠。如果您在此时间锁定流下有多个流或根本没有父级,则限制深度重叠搜索的时间锁定流并不是非常有用。
现在有一种简化的方法,涉及创建change palettes,但它仍然不方便。如果在流下有可用于重叠合并的工作区,则应在流级别提供合并菜单项。
注释工具非常笨拙:
当引入新的流收藏夹时,上下文菜单项“添加到流过滤器”被删除了。应该可以右键单击流并将其添加到某个流收藏夹中(第二级上下文菜单或弹出对话框)。现在编辑流收藏夹非常麻烦,尤其是当您需要拥有2组相似的流时。
将流名称复制到剪贴板应该很容易。现在你需要打开“更改流”对话框。在流浏览器中按Ctrl+C可以将所选流的名称复制到剪贴板中。 无法从流视图中复制流名称。右键单击选项卡可以复制流名称到剪贴板,或者在上下文菜单中显示“复制流名称到剪贴板”的项目。
仅显示行中的第一个不同字符,而不是整行差异,并且不会突出显示语法。幸运的是,差异工具可以轻松切换为外部工具,因此这只是小问题。
在过去的三年中,AccuRev从此列表中添加了3个功能(我已将它们删除,因为它们已经实现):
除了GUI之外,AccuRev整体存在基本缺陷:
您无法轻松地向后更新。有accurev update -t <transaction-number>
命令,但如果您更新到事务100,则无法使用accurev update -t 95
更新到事务95。为了做到这一点,您需要在备份流上设置时间锁定(这将在AccuRev中引入事务),然后更新您的工作区。
当您更新时,可能会发现源状态无效而没有任何通知。这是由于重叠功能。重叠基本上是冲突(当文件被您和他们同时更改时)。如果您的工作区中有重叠,则在允许更新之前,您需要先将其合并。但是,如果您的工作区下面有流中的重叠,则不会收到任何通知,但是重叠的文件将不会在您的工作区中更新。考虑以下流结构
[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
。我在现任工作中度过的最棒的一天之一,是我们放弃使用Accurev转而使用Subversion。Accurev使用了过于复杂的概念。就像上面的评论者们所说,在使用它多年后,我仍然不理解艺术品可能处于的不同状态。似乎Accurev最大的优点是其白皮书和流可视化,这两个特性对管理层非常吸引人,但这对开发人员没有任何帮助。我在不同的项目中使用Subversion、Mercurial和Git,并推荐这些工具。
我长期使用Accurev,最近换了工作开始使用Perforce。我必须告诉你,我希望我能回到Accurev。我同意 - UI很慢并且存在问题。
然而,它有一些真正令人敬畏的可视化工具。我无法相信任何人会看着版本历史浏览器而不爱上它!流浏览器是一个伟大而简单的工具,可以了解开发组织中正在发生什么。
此外,它的管理非常简单。Accurev实际上是我最喜欢的工具之一。