有选择地在TFS分支

我们允许外部顾问在我们的部分来源工作。我们创建了一个新的TFS项目并授予他们相应的权利。分支在TFS项目之间起作用，因此我们可以将他们正在开发的“真正的”TFS项目分支到咨询项目。但是，我们只想暴露部分内容。这正是我们想要的（简化）：有选择地在TFS分支

 
OurProject 
    Mainline 
    Applications 
     Secret1 
     NewApp 
    Libraries 
     Secret2 
     Shared 

ConsultantProject 
    Mainline-Branch 
    Applications 
     NewApp 
    Libraries 
     Shared

如果我们只是分支主线和删除分支中的秘密文件夹，合并背部必须小心避免删除主线秘密文件夹。我们希望简化未来的合并（两种方式），同时最大限度地降低风险。

这是如何实现的？

来源

2010-01-08 TrueWill

我知道这可能不会回答你的问题，而是你问题的意图。为什么不设置权限来隐藏咨询顾问和分支机构的秘密项目？

来源

2010-01-08 19:49:35 Alex

+1，保持简单 –

而不是分支，然后从分支中删除文件/文件夹，只分支您希望他们有权访问的文件。

如：

分公司干线 - > $/ConsultantProject /主线分支。
右键单击$/ConsultantProject/Mainline-Branch/Applications/Secret1并撤消结帐。
同样可以在$/ConsultantProject/Mainline-Branch/Libraries/Secret2上取消签出。
检查你的分支（$/ConsultantProject /）。

完成此操作后，从一个合并到另一个不会影响您未分支的文件/文件夹。

来源

2010-01-08 18:44:11

对不起，这是不正确的。如果他们遵从你的建议，TFS将在每次从Mainline合并时尝试分支Secret1和Secret2。他们将被迫逐个文件夹合并。 –

对不起，自从我合并我们以这种方式处理的项目以来，已经有一段时间了。你是正确的，合并树干分支将尝试分支Secret1＆Secret2;但是，只要合并此方向，对这些文件夹重复“撤消签出”步骤并不困难。然而，这种方法简化了合并分支到主干，所以仍然是他的问题的有效解决方案。 –

+1努力 - 谢谢！ – TrueWill

TFS真的很喜欢项目的所有依赖关系在一个文件夹内。我会重新调整文件夹的布局。这是我将如何去做的。

TeamProject 
    SecretApplication 
     SharedLibrary1 
    Application1 
     SharedLibrary1 
    SharedLibrary1 
    ConsultantApplication1 
     SharedLibrary1

这里的细节...

通知所有的应用程序是如何同行？ SharedLibraries被共享/分支到使用它们的应用程序中。这样，应用程序可以按照自己的步调前进并根据自己的步调取消共享的更改，并按自己的步调将其更改合并到共享代码中。 TeamProject-> SharedLibrary1是SharedLibrary1的“主线”。在其他地方你看到SharedLibrary1，它是一个分支。每个应用程序文件夹都是自己的“主线”，使您的结构更加以应用程序为中心，而不是“我们所有的工作”为中心。

使用此设置，您只需创建Application1的分支并将其称为ConsultantApplication1。通过这种方式，您可以设置安全性，让您的顾问只能看到一个应用程序及其所有依赖项。他们可以合并并随意拉动。那么，如果没有看到源项目，他们将无法合并，但你可以。团队项目中的所有其他应用程序对他们来说都是不可见的。

让我知道我是否误解了某些内容或者是否有一些要求阻止您使用这样的结构。如果在Application1下有一个秘密共享库，我们就不得不多想一想，但我认为这会有编译问题。无论如何，将一个应用程序的所有依赖关系放在一个文件夹下面会有帮助，这是一个很好的练习。

来源

2010-01-08 18:59:47

这很好，但在我们的情况下根本不可行。我们有一个项目/文件夹结构，适合我们的开发人员;这是我们没有预见到的一项新要求。 – TrueWill

顺便说一下，这样做意味着SecretApplication和Application1不能共享一个库项目，除非它被复制（不寒而栗）或预编译。 VS从另一个文件夹编译项目没有问题。 – TrueWill

VS可以编译另一个文件夹中的项目，但是您不会从该设置获得任何源代码控制优势。如果SecretApplication和Application1都有SharedLibrary1的分支，那么他们在开发中可能会发生分歧。它们可以屏蔽某些其他应用程序可能必须在库中制作的更改，并可在准备就绪时获得最新版本或合并版本。这不是简单地链接到它的home/source文件夹中的库的主要好处。虽然我听到你已有的条件。在大型旧版应用上重构源文件夹可能很困难。 –

我同意亚历克斯。 TFS没有任何内置机制来处理稀疏分支。 TFS中最接近的模拟是通过标签进行分支/合并，但是这种策略带来了大量的管理开销，这是非常容易出错的。

所以，让分支/合并系统做它的事情，并使用ACL来确保你的顾问不能看到秘密酱油。

请注意，为了完全安全，您需要为他们创建第二个解决方案，该解决方案不包含任何Secret项目，然后ACL将主要（全包）解决方案视为不可见。非秘密项目是否依赖于秘密项目？如果是这样，你将不得不做类似的事情（虽然稍微牵涉一点）。

来源

2010-01-09 01:35:18

+1 - 感谢您的详细信息！ – TrueWill

有选择地在TFS分支

回答

相关问题