通过复制现有项目在TFS中创建全新项目的最佳方法是什么？
我有一个ASP.NET项目,每年将有50多个"发布".每个版本都是一个独特的实体,需要保持独立于其他版本.一旦创建,我想确保对一个(源项目或副本)的任何更改不会影响另一个.
这仅适用于源代码管理.我不需要复制任何工作项.
在TFS之前的世界中,我只需复制包含所有项目文件的文件夹即可.这让我有90%的新应用程序,然后我可以为新版本定制.我需要实际向基础应用程序添加功能是非常罕见的,即使我这样做也不会影响现有的应用程序.使用TFS仍然可以通过复制我的本地文件夹,然后将副本作为新项目添加到TFS中吗？
有什么建议？每个版本的一个分支看起来像这样做的"标准"方式,但我很快会得到几十个真正无关的分支,我宁愿把每个新项目都保留为它自己独特的项目,没有机会一个影响另一个的变化.
谢谢!
这里有两个问题:
1)复制/粘贴或分支是否更好？
我冒昧地说复制/粘贴永远不合适.除非你非常小心(至少在复制之前立即运行'tfpt treeclean'),否则你最终可能会检查一些不适当的文件到新位置.此外,您将在服务器上使用更多的FAR磁盘空间,因为它必须存储50多个完整副本而不仅仅是差异.
实际上没有任何危险,分支将"意外"变得混乱.将分支合并在一起涉及至少3个故意步骤:挂起合并(本身是一个4页的向导),然后解决所有冲突,然后签入.
你也不会对你在树上的位置感到困惑.TFS使用"路径空间"分支.这意味着分支在用户树中显示为源树中的单独物理位置,而不仅仅是同一路径上的版本标记.由于分支看起来像文件夹,你可以对它们执行所有正常的文件夹操作:披风(不要将它们下载到你的本地工作区),权限(特别是删除别人的读取权限将确保他们甚至看不到它),删除或销毁(当你真正完成它们时).
2)何时适合创建新的团队项目？
但是,我会说你的情况很简单:不要这样做.团队项目有很多开销.你可以在服务器上创建一个有限的数字 ......永远.不要忘记其他形式的开销,例如项目管理员移植所有设置所花费的时间,以及团队中每个开发人员重新连接其团队资源管理器所花费的时间.
全是为了什么？上面的链接详细介绍了可以在单个团队项目中创建的子结构形式.简而言之,几乎任何事都有可能.有些缺乏的领域是团队查询和构建定义,它们仅限于一个容器文件夹,还有一些像Exclusive Checkout这样的设置,它们都是全有或全无.除非你有一个非常庞大或非常多样化的团队,否则每个版本的独立团队项目的好处不可能超过缺点.
当然,如果"发布"是一个重大事件,表明您的SCM实践发生了变化,那就是另一个故事.新SCM =>新流程模板=>新团队项目.但我怀疑你每年做50次以上:)
| 归档时间： |
|
| 查看次数： |
21494 次 |
| 最近记录： |