我在一篇关于Version Insight(http://www.delphifeeds.com/go/s/77066)的博客中读到了(其中包括)JCL没有版本控制下的.dproj文件,我想知道它的优点是什么那会是.
特别是因为我和我的同事开发人员经常通过使用我们自己喜欢的调试设置检查项目文件而互相"错误"(他喜欢优化,我希望它关闭).而且由于Delphi 2007的常规问题,dproj文件被各种错误的依赖项搞砸了.版本控制无论如何都不能帮助这些东西吗?
我们目前正在使用Starteam作为我们的VCS.
有没有一个工具可以将Starteam迁移到svn或git或任何其他现代/体面的源代码控制系统?
我正在考虑一些git-svn有效的方法; 允许您使用git从svn存储库中提取.
可以导入StarTeam存储库并将其转换为svn存储库的东西,但也可以从Starteam继续并添加到svn.
地狱,即使是"开始使用cvs"工具也没问题,只要我能在初始迁移后继续从starteam repo中撤出.
这应该是一个RTFM问题,但我找不到它!
我刚刚开始在工作中使用StarTeam,我正在尝试初始化我一直使用Git管理的存储库.我已设法将文件夹添加到我的视图中,但是,我似乎无法检入所有文件.我认为没有人会注意到额外的Git信息,所以有人知道如何递归地向StarTeam添加所有文件和文件夹吗?命令行没问题,我厌倦了与客户打架.
如果重要的是,StarTeam 2006 Release 2
我需要将一个大项目从StarTeam 5迁移到Subversion,我想保留(至少)5-10个主要版本的快照.我考虑过以下几点:
我很感激您提供的任何经验或建议.谢谢.
我们有一个小团队负责运行StarTeam.持续不断的挫败感和问题是在StarTeam中处理已删除的文件.很明显,Starteam会在内部跟踪已删除的文件,但似乎无法获取有关文件删除的任何信息.
到目前为止,我找到删除时间的唯一解决方案是使用"比较"视图执行手动二进制搜索.有没有更好的方法('删除时间'的查询似乎永远不会拿起任何文件).
是否有适合Eclipse的插件允许与StarTeam集成?
我想念曾经与CVS/SVN有过的"紧密"整合.
Jenkins(Hudson)拥有StarTeam插件.如何正确配置?
我已经安装了这个插件,但是当我构建项目时,我收到了这个错误:
java.lang.NoClassDefFoundError:com/starbase/starteam/Folder
Machine是Windows Server 2008.我在C:\Program Files (x86)\Borland\StarTeam SDK 10.4文件夹中安装了StarTeam SDK .
我们目前正在为我们的项目使用StarTeam,许可证即将到期.我们正在考虑迁移到Team Foundation Server或类似的东西,但是有一种推动(主要是来自我自己和另一个人)转向某种形式的分布式版本控制.其中一个问题是我们的变更经理希望能够通过变更请求进行跟踪和发布(如在StarTeam中),我不相信这可以通过Mercurial或Git开箱即用(请如我错了请纠正我).
这是一个拥有15年历史的产品,拥有数千个java文件和PL/SQL包,由5-6个开发子团队维护,共有30-40个开发人员.对我而言,这似乎会使分布式存储库成为"早期提交,经常提交"思维模式的噩梦.事实上,每个团队都在同一个存储库中处理一个完全不同的子系统,这使得它在我的脑海中变得更加糟糕.
我们目前的StarTeam流程适用于任何变更:
就个人而言,我认为"锁定"文件的想法是荒谬的.团队之间应该有足够的沟通,这是你不需要的.
这里有没有人在类似大小的项目上有分布式存储库的经验?您能对版本控制和/或变更管理解决方案提出任何建议吗?主要要求是系统能够管理客户发起的变更请求,并迫使开发人员将其签到链接到一个.
谢谢.
我一直在使用StarTeam进行版本控制,但我正在转向Subversion.我一直在阅读Subversion书籍,StarTeam似乎有一个主要功能,Subversion没有 - 标签的概念.我知道Subversion有标签,但它们在StarTeam中意味着不同的东西.在StarTeam中,我可以将一组文件标记为"准备构建",然后仅检查这些文件并包含在特定版本中.然后,我可以创建一个冻结标签,指示该版本中包含哪些文件(类似于Subversion标记,除了它在那些特定的修订版上,而不是目录中的所有内容).
有没有办法在Subversion中获得这样的功能?我知道您可以指定要标记的修订版本,但是在您拥有代码并即将执行发布,发现错误或某人决定不应包含特定更改的情况下会发生什么.我知道您可以根据存储库和本地工作副本创建标记,但这涉及检查不应包含的文件的特定修订并创建标记.准备好构建"标签",您不会将该标签放在您不想要的文件的头版本上.没有任何自动方法可以为Subversion中的构建指定某些修订.这不是应该在分支中开发新功能的情况,但如果修订在主干中(或者您将从哪里制作标记),则更多,但不应包括在内.它可能不需要恢复 - 改变可能是适当的,但在未来的版本中,而不是当前版本.如果您没有具有所需文件版本的特定版本,则似乎您必须手动混合和匹配存储库和工作副本.
在类似的情况下,如果Subversion中的文件不属于发行版并且不需要标记,该怎么办?在StarTeam中,您不会将准备构建标签附加到它们,但在Subversion中,它似乎是目录中的所有内容.有没有办法从构建和标记中排除这些文件?这是svndumpfilter排除的用途吗?
简而言之,有没有办法只在标记中包含某些文件的特定修订版,或者它必须是存储库中的特定修订版,还是存储库中的文件和工作副本的手动混合?
我们有一个StarTeam视图,其中有两个处于"未知"状态的文件 - 是否有人理解为什么他们处于这种状态和/或我们如何让他们离开状态?
是删除它们并使用其他名称重新添加它们唯一的解决方案?
请注意,如果您检查这两个文件(定期或使用"强制结帐"),它们将始终列为"未知"(烦人).
谢谢.
更多信息基于Craig的建议如下:
a)使用MD5校验和计算文件状态:相同的结果("未知"状态)
b)这两个文件在服务器上只有一个版本.我不确定这是不是因为我们的CM小组试图通过删除和重新创建文件来解决问题,或者是否真的只有一个版本.这些文件是文本文件.
c)我尝试删除本地计算机上的文件并刷新状态.当我这样做,而不是看到列出为"未知"的两个文件,我看到总共有四个文件列出状态为"丢失".每个文件都列出了两个条目 - 每个条目具有相同的文件名,文件夹路径,"修改者"和"签入时的文件戳".我不知道为什么每个文件都列出两次.如果我选择一对中的每个条目并选择"比较内容",我的差异工具说它们是相同的.
无论是使用MD5校验和比较还是非MD5,我对这四个文件都有同样的奇怪问题.
如果我尝试检出所有四个丢失的文件,我会收到两个警报,提示我合并文件.我说不,文件现在在我的本地文件系统上,状态又回到我开始的位置 - 两个文件列为"未知".
克雷格的更新:
你肯定是在做点什么.我将每个重复的项目移动到另一个目录.这立即解决了这个问题,因为我现在可以在没有任何"未知"项目的情况下签出四个项目(两个在同一个目录中,两个在新目录中).然后我删除了我移动到新目录的两个项目.
在这样做的过程中,我看到了更多信息.我们不知何故有这样的目录结构:
Parent_Dir
--SubDir1
--SubDir1
--SubDir1
--SubDir1 <- Two items were here
--SubDir1 <- Two items were here
--SubDir2
--SubDir3
--SubDir4
--SubDir5
Run Code Online (Sandbox Code Playgroud)
不知何故,我们有五个具有相同名称的子目录,这两个文件存在于两个具有相同名称的子目录中.
问题似乎已得到解决.你认为我应该手动删除额外的子目录吗?
感谢Craig这个问题似乎已经解决.我不知道这种情况是如何产生的(任何人?)但是......我们现在很好.谢谢克雷格!
我们正在从StarTeam(又名"可怕的")迁移到SubVersion(又名"所谓的伟大").我们已经通过对所有文件执行"哑"提交来迁移文件,并开始使用SubVersion存储库.
但是,我们仍然被迫使用StarTeam,因为我们缺少签到的每个文件的历史记录.在第一次办理登机手续后,是否可以将该历史记录注入SubVersion?如果是 - 如何?
我想知道如何在SVN中执行以下常见的StarTeam任务
1.如何更新标签以包含仅1个文件的较新版本?
在StarTeam中创建视图标签后(类似于SVN中的标签) - 我能够在该视图标签中包含更新的文件版本 - 例如,更新视图以仅包含该文件(而不包括自该文件以来也发生更改的其他文件)创建该视图标签
2.如何根据另一个标签创建标签?
在发布版本的同时继续开发时,虽然签入了一些功能,但是不会包含一些功能.在StarTeam中,我曾经基于先前的视图创建了一个视图标签(再次像标签一样)(然后执行我描述的内容)问题1).据我所知,在SVN我可以创建一个基于另一个的标签,但它是只读的,我需要一个分支.但我真的不需要分支机构.
3.如何签入/添加现有标签?
在StarTeam中,视图标签位于主干/分支上,因此我可以在创建视图后检入文件并修改标签以包含它,在SVN中我必须检查分支
是否可以使用stcmd签出特定修订的文件?
我想查看特定文件的所有(或某些)历史记录.