TFS:从TFS中的现有项目创建新项目

TFS:从TFS中的现有项目创建新项目,tfs,Tfs,通过复制现有项目在TFS中创建全新项目的最佳方法是什么 我有一个ASP.NET项目,每年将有50多个“版本”。每个版本都是一个独立的实体,需要保持独立于所有其他版本。创建之后,我希望确保对其中一个(源项目或副本)的任何更改都不会影响另一个 这仅用于源代码管理。我不需要复制任何工作项 在TFS之前的世界中,我只需复制包含所有项目文件的文件夹就可以做到这一点。这让我有90%的时间使用新的应用程序,然后我就可以为新版本量身定做。我很少需要向基础应用程序实际添加功能,即使这样做,也不会影响现有应用程序。

通过复制现有项目在TFS中创建全新项目的最佳方法是什么

我有一个ASP.NET项目,每年将有50多个“版本”。每个版本都是一个独立的实体,需要保持独立于所有其他版本。创建之后,我希望确保对其中一个(源项目或副本)的任何更改都不会影响另一个

这仅用于源代码管理。我不需要复制任何工作项

在TFS之前的世界中,我只需复制包含所有项目文件的文件夹就可以做到这一点。这让我有90%的时间使用新的应用程序,然后我就可以为新版本量身定做。我很少需要向基础应用程序实际添加功能,即使这样做,也不会影响现有应用程序。通过使用TFS,复制我的本地文件夹,然后将副本作为新项目添加到TFS中,这是否仍然可行

有什么建议吗?每个版本一个分支看起来像是“标准”的方式,但我很快就会得到几十个真正不相关的分支,我更希望每个新项目都保持它自己的独立项目,一个项目的更改不会影响另一个项目

谢谢

  • 谢谢你的回复。我想你们都给了我足够的洞察力让我开始。理查德,谢谢你提供的细节。我有点担心意外地合并分支可能太容易了

我建议使用分支。从主分支为每个版本创建一个分支。只要不合并分支,它们将保持独立。对主分支的更改只会影响在进行这些更改后创建的版本

您可以复制文件并创建新项目,但可能会遇到几个问题:

  • 这些项目“记住”它们在TFS中,有一些手工工作来清理特殊文件等
  • 与具有分支的单个项目相比,当您有许多项目时,TFS可能会减慢速度

    • 这里有两个问题:

      1) 复制/粘贴或分支更好吗

      我敢说复制/粘贴从来都不合适。除非您非常小心(至少在复制之前立即运行“tfpt treeclean”),否则很可能最终会将一些不合适的文件检入到新位置。此外,您将在服务器上使用更多的磁盘空间,因为它必须存储50多个完整副本,而不仅仅是差异

      实际上,分支“意外地”沿着线路缠绕在一起是没有危险的。将分支重新合并到一起至少需要3个步骤:暂停合并(本身是一个4页的向导),然后解决所有冲突,然后签入

      你也不会对自己在树上的位置感到困惑。TFS使用“路径空间”分支。这意味着分支在用户看来是源树中单独的物理位置,而不仅仅是同一路径顶部的版本标记。因为分支看起来像文件夹,所以您可以对它们执行所有正常的文件夹操作:隐藏(不要将它们下载到本地工作区)、权限(特别是,删除某人的读取权限将确保他们甚至看不到)、删除或销毁(当您真正处理完它们时)

      2) 什么时候创建新的团队项目合适

      总的来说,这是一个更复杂的话题

      然而,我认为你的情况很简单:不要这样做。团队项目有很多开销。有一个…永远。不要忘记其他形式的开销,比如项目管理员移植所有设置所需的时间,以及团队中每个开发人员花费在重新连接其团队资源管理器上的时间

      都是为了什么?上面的链接详细介绍了可以在单个团队项目中创建的子结构的形式。简言之,几乎任何事情都是可能的。唯一缺少的地方是团队查询和构建定义(仅限于单个容器文件夹)以及一些设置(如独占签出),这些设置要么全有,要么全无。除非您有一个非常大或非常多样化的团队,否则每个版本单独的团队项目的好处不太可能超过缺点


      当然,如果“发布”是表明SCM实践发生变化的重大事件,那就完全是另一回事了。新SCM=>新流程模板=>新团队项目。但我怀疑你一年做50多次:)

      这听起来很明显,但你应该只为“新项目”创建一个新项目。听起来你说的是同一个项目的不同版本

      如果您想为以前的版本维护单独的代码库,那么正如其他回答者所说的,分支代码是您最好的选择。当您希望将最新版本中的bug修复程序合并到较旧版本中时,这种方法也能很好地工作

      然而,如果你真的必须有新的项目,你仍然以同样的方式使用分支。

      “官方指南”链接已经失效。