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