Perforce、Visual Studio 和分支
我们正在尝试在我们的小型 IT 部门实施 perforce。我们主要使用 Visual Studio 2008 在 .net 中进行开发。我按如下方式组织我的项目：
Customer
Product
main_line
version_1
version_2
Libraries
Library_Name
main_line
version_1
main_line/version 文件夹包含解决方案文件以及解决方案中主项目的代码文件。该解决方案通常包括“库”层次结构中包含的一个或多个项目，并且这些库项目通常包含在多个解决方案中。实际上，只要我将源代码控制应用于单个项目而不是整个解决方案，这似乎就可以正常工作。事实上，如果我尝试共享公共项目/库的源代码控制解决方案，perforce 插件或 Visual Studio 本身都会向我发出警告。
当我尝试分支解决方案时，问题就开始发生。由于我不是对整个解决方案进行源代码控制，因此 .sln 文件不会复制到分支目录，我怀疑由于文件映射不正确，该文件无论如何都是无用的。我的问题是，我是否做错了什么，或者视觉工作室解决方案的分支总是如此痛苦？有更好的办法吗？ Perforce 似乎只适用于简单的解决方案。有没有更适合 Visual Studio 的源代码管理产品？
We are in the process of trying to implement perforce in our small IT department. We're primarily developing in .net using visual studio 2008. I've organized my projects as follows:
Customer
Product
main_line
version_1
version_2
Libraries
Library_Name
main_line
version_1
A main_line/version folders contain the solution file as well as the code files for the main project in the solution. The solution typically includes one or more projects contained in the "Libraries" hierarchy, and those library projects are usually included in multiple solutions. In perforce this seems to work fine as long as I apply source control to individual projects as opposed to entire solutions. In fact, either the perforce plug-in, or visual studio itself, gives me a warning if I try to source control solutions that share common projects/libraries.
The problems start happening when I try to branch solutions. Since I'm not source controlling the entire solution, the .sln file is not copied to the branch directory, which I suspect is would be useless anyway due to incorrect file mappings. My question is, am I doing something wrong or is branching of visual studio solutions always this painful? Is there a better way? Perforce seems work well only for simple solutions. Is there a source control product that works better with visual studio?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我认为 Perforce 是问题的一小部分。您没有提到当您尝试共享公共项目/库时遇到的具体问题，也没有提到您如何尝试做到这一点。
我假设您想为每个产品版本使用稳定的库版本？我建议您将正确版本的库分支到产品仓库路径下的位置。根据项目的性质，您还可以在产品工作区中构建库并签入工件（例如 dll），以实现简单且可重复的构建。示例：
将“//depot/customer/product/MAIN/deps/src/lib1/...”路径视为只读。按照惯例执行此操作是最简单的方法，但您可以在 Perforce 中自定义保护映射来强制执行此操作。不过，除非您确实确定需要它，否则不要这样做，因为这会增加复杂性。
完成此操作后，您可以轻松地将整个产品的解决方案文件添加到 Perforce。 （该解决方案不需要“直接”引用该库，因为您不会在产品的上下文中使用它。）
根据产品的性质和组成，您可能会相反，希望对产品的不同部分（exe、lib、安装程序）使用“子解决方案”，以便在产品的不同部分上同时工作变得更容易。 Perforce 具有出色的合并功能，但我更喜欢尝试避免合并解决方案/项目文件。
然后，当您想要发布“产品”的新版本时，请将 MAIN 下的所有内容分支到例如 REL1（包括依赖项部分）。如果新产品版本需要更新版本的库，您只需“p4 删除”产品库路径下的适用内容，然后如上所述分支/集成正确的版本。
注意：应该可以将新版本的库集成到产品的例如 deps/libs/src/lib1/ 位置，因为它们具有共同的祖先。不过，我对此并不是 100% 确定，所以我建议从 p4 删除/集成新方法开始。
注意2：解决方案和项目文件内的路径通常与解决方案/项目文件本身相关，因此分支在这方面应该可以正常工作。只是不要自己使用绝对路径添加对其他文件/目录的引用。
I think that Perforce is the lesser part of the problem. You don't mention what specific problems you're seeing when you try to share common projects/libraries, and neither how you try to do it.
I assume that you want to use stable library versions for each product version? I'd recommend you to branch the library at the correct version to a location under the product's depot path. Depending on the nature of your project you could then also build the library inside the product workspace and check in the artifacts (e.g. dlls) for easy and reproducible builds. Example:
Treat the "//depot/customer/product/MAIN/deps/src/lib1/..." path as read-only. Doing this by convention is the easiest way, but you could customize the protection mapping in Perforce to enforce this. Don't do it unless you are really sure you need it, though, as you'll be adding complexity.
Once you've done this you can easily add the solution file for the whole product to Perforce. (The solution does not need to reference the library "directly" as you won't be working on it in the context of the product.)
Depending on the nature and composition of your product you'll probably instead want to use "subsolutions" for different parts of the product (exes, libs, installers) to make it somewhat easier to work concurrently on different parts of the product. Perforce has excellent merging capabilities, but I prefer to try and avoid merging solution/project files.
When you then would like to release a new version of "product", branch everything under MAIN to e.g. REL1 (including the dependencies part). If the new product version needs an updated version of the lib you could just "p4 delete" the applicable stuff under the product depot path and branch/integrate the correct version as described above.
NOTE: It should be possible to just perform an integration from the new version of the lib into the e.g. deps/libs/src/lib1/ location of the product, as they have common ancestors. I'm not 100% sure about this though, so I would recommend starting out with the p4 delete/integrate new approach.
NOTE2: Paths inside the solution and project files are generally relative to the solution/project file itself, so branching should work just fine in this respect. Just don't add references to other files/directories using absolute paths yourself.
我设法很好地解决了这个问题。对我来说似乎出现问题的是我的解决方案文件（.sln）与我的启动/主项目的代码位于同一目录中。我将项目代码移至其自己的子文件夹，位于实际解决方案的下一级。
这使我能够使 sln_file 中的所有项目引用相对。然后我通过 Visual Studio 插件将 src 文件夹中的代码添加到仓库中。我单独添加项目，而不是整个解决方案。唯一的问题是我必须直接通过 p4v 管理 sln 文件，但由于它不会经常更改，所以这并不是真正的问题。现在，当我分支 main_line 时，我得到了 .sln 文件的副本，以及相对引用，并且一切都按预期工作。
I managed to get this worked out pretty well. What seemed to cause a problem for me was having my solution file (.sln) in the same directory as the code for my start-up/main project. I moved the project code to it's own sub-folder at one level below the actual solution.
This allowed me to make all of the project references in the sln_file relative. Then I add the code in the src folder to the depot via the visual studio plug-in. I add the projects individually, not the entire solution. The only issue is that I have to manage the sln file through p4v directly, but since it doesn't change all that often anyway, this isn't really a problem. Now, when I branch main_line, I get a copy of the .sln file, with relative references, and everything works as expected.