删除分支层次结构中的主干并仅具有相同级别的分支
我决定将我的 TFS 解决方案分为 4 个分支。我最初有一个受源代码控制的 VS 解决方案，称为“开发”。随着产品的发展，我决定为使用它的三个客户创建 3 个分支。所以我有：
- Development
- Development-Client1
- Development-Client2
- Development-Client3
我有一个针对“Development-Client2”的新更改请求，并编写了代码并进行了更改。当我检查源文件时，我注意到“开发”也考虑了这些新的更改。
当我分支“开发”时，我期望发生的是，我将拥有 4 个版本的解决方案，并且我可以合并它们之间的变更集。
从我当前的设置来看，我在#2、#3 或#4 中所做的任何更改似乎都会自动添加到#1 中。
由于最近发生了分支，我觉得我现在可以解决这个问题。有谁知道我需要什么才能获得 4 个独立的分支机构？
更新
在我的解决方案文件中，我有 6 个项目：
- ASP.NET 网站（针对本地主机运行）。
- 控制台应用程序
- 类库（业务逻辑）
- 类库（数据访问）
- 类库（实体）
- 类库（常用方法）
我注意到，对于“Development-Client2”中的新功能，项目 2-6 中的更改尚未生效添加到“开发”分支或“开发-客户端1”或“开发-客户端3”分支。
但是，我对“Development-Client2”中的“ASP.NET 网站（针对本地主机运行）”所做的任何更改都已复制到所有分支中。
更新 2
我认为发生了什么，在以下顺序是：
- 我有一个名为 Development under source control (TFS) 的解决方案
- 我创建了一个名为 Development-NewFeatureX 的分支
- 我对 Development-NewFeatureX 进行了 3 次分支，剩下了 Development、Development-NewFeatureX、 Development-Client1、Development-Client2、Development-Client3
- 我删除了 Development-NewFeatureX 分支。
- 我对 Development-Client2 分支下的项目 1、3、4 和 5 进行了大量更改。
- 此时，我意识到项目 1 的更改已复制到其他分支。
我还注意到，在 TFS 的源资源管理器部分中，每个分支的解决方案文件是指向项目 [ASP.NET 网站（针对本地主机运行）] 的“Development-NewFeatureX”。
我尝试查看解决方案文件并修改路径：
..开发-NewFeatureX/ASPNETSITE
：
..开发-ClientX/ASPNETSITE
但是，这不起作用，源代码控制似乎正在覆盖解决方案文件。
我认为现在是我承认失败并尝试开始新的解决方案的时候了。
如果任何 TFS 专家知道我在说什么，请给我一些建议
问题摘要
- 我有 4 个分支。
- 每当我打开项目的任何分支的解决方案文件：“ASP.NET 网站（针对本地主机运行）”时，它都没有什么不同。即它是同一个。因此，如果我在任何分支中对这个项目进行更改，它就会跨越所有分支。
- 这个有问题的项目的映射文件夹是我之前删除的分支。
- TFS 的结构对于分支/项目来说似乎是正确的。只有当我打开解决方案文件时，ASP.NET 站点才始终是同一个站点。
- 请看截图。
I have decided to branch my TFS solution into 4 branches. I originally had one VS solution that was under source control, called 'Development'. As the product grew I decided to create 3 branches for the three clients that use it. So I have:
- Development
- Development-Client1
- Development-Client2
- Development-Client3
I had a new change request for 'Development-Client2' and wrote the code and made the changes. When I checked the source files in I noticed that 'Development' is also taking these new changes into account.
What I expected to happen, when I branched 'Development', was that I would have 4 versions of the solution and I could merge changesets between them.
From my current set up, it appears that any changes I make in #2, #3 or #4 will be automatically added into #1.
Since the branching occurred recently I feel I am in a position to sort it out now. Does anyone know what I need to to to get 4 independent branches?
UPDATE
In my solution file I have 6 projects:
- ASP.NET Web Site (running against localhost).
- Console Application
- Class Library (Business Logic)
- Class Library (Data Access)
- Class Library (Entities)
- Class Library (Common Methods)
I have noticed that for my new features in 'Development-Client2' that the changes in projects 2-6 have not been added to the 'Development' branch or the 'Development-Client1' or 'Development-Client3' branches.
However, any changes I made to the 'ASP.NET Web Site (running against localhost)' in the 'Development-Client2' have been replicated into all branches.
UPDATE 2
What I think has happened, in the following order, is:
- I had a solution called Development under source control (TFS)
- I created a branch called Development-NewFeatureX
- I branched Development-NewFeatureX 3 times, I was left with Development, Development-NewFeatureX, Development-Client1, Development-Client2, Development-Client3
- I deleted the Development-NewFeatureX branch.
- I made loads of changes to projects 1, 3, 4 and 5 under the Development-Client2 branch.
- At this point, I realised that project 1's changes had been replicated across the other branches.
I have also noticed that in the Source Explorer part of TFS that the each of the branches' solution file is pointing at 'Development-NewFeatureX' for the project [ASP.NET Web Site (running against localhost)].
I have tried to check out the solution file and modify the path from:
..Development-NewFeatureX/ASPNETSITE
to:
..Development-ClientX/ASPNETSITE
However this is just not working and source control seems to be overwriting the solution file.
I think it is at the point that I concede defeat and try to start a new solution.
If any TFS gurus have any idea what I'm talking about please give me some advice
SUMMARY OF PROBLEM
- I have 4 branches.
- Any time I open the solution file of any of the branches the project: "ASP.NET Web Site (running against localhost)" it is not different. i.e. it's the same one. So if I make a change on this project in any branch it is across all of them.
- The mapped folder of this problematic project is the branch that I deleted previously.
- The structure of TFS seems correct with the branches/projects. It is only when I open the solution file that the ASP.NET site is always the same one.
- Please see screenshot.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
根据我的经验，VS 总是需要从本地主机控制网站。
这是一直对我有用的方法：
我想你的情况发生了什么：你使用了 File ->新的网站项目，它将项目放入解决方案文件中，然后将该网站连接到客户端解决方案中，因为它位于同一位置。从那时起，TFS 就从同一个地方为所有客户挑选文件。这是皮塔饼。
In my experience VS always required handholding with websites from localhost.
Here's what always worked for me:
I think what happened it your case: you have used File -> New Web Site project, it placed the project into solution file and then you connected that Web Site into your Client solution as it was in the same location. Since then TFS was picking his files from the same place for all clients. which is pita.
有几件事要尝试。
自 2010 年以来：您是否尝试过在分支可视化工具中跟踪您的变更集之一？选择在您的孙子分支之一中进行的特定变更集，您认为该变更集已将自身复制回其他分支，然后查看 TFS 认为它去了哪里？如果它在其他分支中亮起，并带有新的变更集编号，则表明已发生合并。然后您可以找到合并变更集并查看它是如何形成的。
如果没有合并，那么您认为从其他地方复制的其他分支中的特定文件的历史记录又如何，并检查它们的差异以了解它们的更改来自哪里？
您检查过 IIS/虚拟目录设置吗？每个分支是否都指向正确的虚拟目录？
您设置了多少个本地工作区以及它们是如何配置的？ TFS 中的多个工作区可能会导致混乱，因为您在源代码管理资源管理器中查看的工作区可能与您在“待处理更改”窗口中看到的工作区不同，这可能会导致签入到您想要的位置之外的其他位置。
最后，我很好奇 - 您希望分支与祖父母和彼此分离的原因是什么？我不清楚删除该父分支并将其全部切断的好处/动机； TFS 不希望保留这些父/子关系吗？或者它足够聪明，能够记住吗？
A few things to try.
Since you have 2010: have you tried tracking one of your changesets in the branch visualizer? Pick a specific changeset made in one of your grandchild branches that you think replicated itself back to the other branches and see where TFS thinks it went? If it's lit up in the other branches, with new changeset number(s), then that's indicative that a merge has occurred. Then you can locate the merge changeset and see how it came to be.
If no merges, then what about the history of specific files in your other branches, that you think got replicated in from elsewhere, and check their diffs to see where their changes came from?
Did you check your IIS/virtual directories settings? Is each branch pointing at a correct virtual directory?
How many local workspaces do you have set up and how are they configured? Multiple workspaces in TFS can cause confusion because the one you're looking at in Source Control Explorer may not be the same one you're seeing in Pending Changes window and this can cause checkins to go someplace other than where you intend.
Finally, I am curious - what's your reason for wanting the branches to be detached from their grandparent and from each other? I'm not clear on the benefit of/motive for deleting that parent branch and cutting them all off; doesn't TFS like to have those parent/child relationships preserved? Or is it clever enough to remember?
以下是我如何根据您的情况制定我的分支和开发策略：
在 IIS 的本地计算机上，为每个客户设置一个具有不同端口的网站，并在端口 80 上设置主分支。这样您就可以并行访问所有构建，而无需切换。
此策略将允许您在 Main 中进行一般错误修复或常见功能，并在需要时对客户分支进行 FI。如果需要，您可以从客户对主系统进行 RI，但如果您坚持分支的目的，则实际上不需要这样做。
这还允许您保留稳定的代码版本，以满足每个客户的未来需求或错误修复。
我知道这并不能解决您的问题，但我希望它对您项目的未来布局有所帮助。
Here is how i would lay out my Branching and Development strategy using your situation:
On your local machine in IIS, setup a website with a different port for each customer and the Main branch on port 80. This way you can access all builds parralel without switching around.
This strategy will allow you to do general bug fixes or common features in Main and do an FI into Customer branches when needed. If needed you can do an RI into Main from Customer but you really shouldnt need to if you stick to the purpose of the branches.
This also allows you to keep a version of the code that was stable for future needs or bug fixing for each Customer.
I know this doesnt fix your problem but I hope it helps with the future layout of your projects.