Perforce，多个解决方案之间共享的项目
更新：
事实证明，我们可能在 Visual Studio 2003 中发现了一个错误（我知道......毫不奇怪）。 我们发现，如果使用 Visual Studio（使用将解决方案添加到源代码管理）将解决方案添加到存储库中，一切都会顺利......想想看。
因此，我们正在将 VSS 存储库（如果可以这么称呼的话）转换为 Perforce，并且我们遇到了多个解决方案中包含的项目的问题。
我们的存储库可能看起来像这样...
- //Depot
- DevMain
- 解决方案1
- Project1（构建为 DLL）
- 解决方案2（将项目1作为项目参考）
- 项目2
- 解决方案3（将项目1作为项目参考）
- 项目3
- 解决方案1
- DevMain
当在 Visual Studio 中使用 Solution2 的集成源代码管理时，它会抱怨项目不在当前解决方案文件夹下，我们可能想要移动它。 因为多个解决方案引用了项目 1，所以我们永远无法将其组织到一个解决方案不会抱怨的地方...
最佳实践是将 Project1 构建为 DLL 并将其存储在 Lib 文件夹中吗？ 或者，还有更好的方法？
谢谢。
UPDATE:
So it turns out that we may have found a bug in Visual Studio 2003 (I know...no surprise). We found out that if the solutions were added to the repository using Visual Studio (using Add Solution to Source Control) everything went fine...go figure.
So we're converting our VSS repository (if it can be called that) to Perforce and we're running into issues with projects included in multiple solutions.
Our repository might look like this...
- //Depot
- DevMain
- Solution1
- Project1 (Builds to a DLL)
- Solution2 (Has Project1 as a project reference)
- Project2
- Solution3 (Has Project1 as a project reference)
- Project3
- Solution1
- DevMain
When using the integrated Source Control in Visual Studio for Solution2 it complains that the projects are not under the current solutions folder and we may want to move it. Because multiple solutions reference Project 1 we can never organize it where one solution won't complain...
Is the best practice to just build Project1 to DLL and store it in a Lib folder? Or is there a better way?
Thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我们遇到了类似的问题，并且正在通过客户规范来解决这个问题，就像 @Toby Allen 在他的回答中提到的那样。 然而，随着时间的推移，这会变得非常痛苦（随着客户规范变得越来越复杂，建立新的团队成员变得越来越困难；而且自动化也变得更加复杂，因为事情......“不断变化”:-)）。
最终，我们改进了策略，改用目录结构和分支。 目录结构如下：
请注意，在整个结构（doc/lib/src/solutions）中重复使用相同的结构。 Lib 包含“外部”库 - 项目引用中包含的第 3 方库。 Src 包含属于特定产品的所有项目的平面列表。 然后使用解决方案以多种方式“组合”项目。 我认为 src 目录是一个包含“可用内容”的容器，然后从该容器中选择解决方案并组合项目（根据需要）。
在多个产品之间共享的库进入共享目录。 一旦进入共享目录，它们就被视为独立于产品 - 它们有自己的发布周期，并且永远不会作为源加入到产品中。 通过将共享库发布程序集/程序集分支到产品的 lib 目录 -> 中，将共享库拉入产品中。 从产品的角度来看，第三方库和共享库没有区别。 这使我们能够控制哪个产品正在使用哪个版本的共享库（当产品需要新功能时，它必须在更新版本的共享库中明确分支，就像它包含新版本的第 3 方库一样，以及随之而来的所有优点和缺点）。
总之，我们的结构具有两种“类型”共享库的概念：
We had a similar problem and were approaching it very much like @Toby Allen mentions in his answer, via client specs. However, in time this becomes very painful (setting up a new team member becomes more and more difficult as client specs become more and more convoluted; also automation is much more complicated because things are... "in flux" :-) ).
Eventually, we evolved our strategy to use a directory structure and branching instead. The directory structure is as follows:
Note that the same structure is repeated throughout the structure (doc/lib/src/solutions). Lib contains "external" libraries - 3rd party libraries that are included in project references. Src contains a flat list of all projects that are part of a particular product. Solutions are then used to "combine" projects in any number of ways. I think of src directory as a container with "what is available", solutions are then picking from this container and combining projects (as needed).
Libraries that are shared among multiple products go into shared directory. Once in shared directory, they are treated as independent from products - they have their own release cycle and are never joined to products as source. Shared libraries are pulled into products by branching the shared library release assembly/assemblies into product's lib directory -> from product's perspective there is no difference between a 3rd party library and a shared library. This allows us to control what product is using what version of a shared library (when a product wants new features, it has to explicitely branch in newer release of a shared library, just like it would include a new release of a 3rd party library, with all pros and cons that go with it).
In summary, our structure has concept of two "types" of shared libraries:
解决方案应该是在每次将 Solution1 添加到新项目时将其重新绑定到源代码管理服务器。 （它位于“文件”->“源代码控制”->“更改源代码控制”下。）
这应该只需要在每个解决方案的每个桌面上执行一次。
The solution should be to rebind Solution1 to the source control server each time it's added to a new project. (It's under File->Source Control->Change Source Control.)
This should only need to be done once per desktop per solution.
我不太了解如何将 Visual Studio 与 Perforce 结合使用，但您可能会考虑在需要时创建将 Project1 映射到 Solution2、Solution3 等的工作区视图。
I don't know much about using Visual Studio with Perforce, but you might consider creating workspace views that map Project1 into Solution2, Solution3, etc., where needed.
如果我理解正确的话，您希望文件在磁盘上的存储方式与 Perforce 中的存储方式不同。 如果是这种情况，并且您不能简单地在 VS 中重新定义引用，那么巧妙设计的客户端就可以解决这个问题。
这将为您提供一个结构，其中 Solution1 是解决方案 2 的子目录。
If I understand correctly you want how your files are stored on disk to differ from how it is stored in Perforce. If this is the case, and you cant simply redefine the reference within VS, then a cleverly designed client can do the trick.
This will give you a structure where Solution1 is a sub directory of solution 2.