处理 .net 开发源代码控制的最佳方法是什么？
目前我们正在使用视觉源安全 - 与 Visual Studio 2010 集成 - 显然它不是理想的选择。
我的主要问题是 - 似乎有一个“项目文件”，它跟踪添加到本地项目的所有新项目 - 而且队友之间似乎总是不同步。我们如何在源代码控制系统中更好地处理这个问题？
（我们已将“项目文件”添加到 VSS，并且一旦有人签出文件，我们也会锁定文件 - 以便“项目文件”始终只能由一个人更改。我们还尝试了 SVN 和 AnkhSVN但它似乎损坏了“项目文件”并且也引起了很多焦虑。）
Currently we are using visual source safe - integrated with Visual Studio 2010 - and clearly its not the ideal option.
My main question is - there seems to be a "project file" which keeps track of all new items added to a local project - and that always seems to go out of sync between teammates. How can we handle that better in any source control system?
(We've added the "project file" to VSS and we've also locked down files once someone checks out a file - so that the "project file" is always just altered by one person. We've also tried SVN with AnkhSVN but it seems to corrupt the "project file" and also caused a lot of angst.)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
您需要将项目文件添加到源代码管理中。如果您使用 Visual Studio，这是您应该始终执行的操作。如果不这样做，您将不会从源代码管理中得到太多用处。
困难的部分是确保人们在完成更改后重新检查。在从源代码管理中拉取项目文件之前，开始让人们签入项目文件。
为什么说VSS不是理想的选择？
如果您正在寻找替代方案，我建议将 Visual SVN Server 与 Ankh SVN 结合使用。两者都是免费的并且对我来说效果很好。
You need to add your Project file to source control. This is something you should always do if you are using Visual Studio. If you don't, you won't get much use out of source control.
The hard part is making sure that people check it back in when they are done making changes. Start making people check in the project file before you pull it down from source control.
Why do you say that VSS is not the ideal option?
If you are looking for alternatives, I recommend Visual SVN Server in conjunction with Ankh SVN. Both are free and have worked well for me.
如果您想走 Microsoft 路线，那么 TFS 是带有一堆功能的新 VSS额外的东西。
我很高兴使用 Subversion 运行 Subversion nofollow">TortoiseSVN 和 Visual Studio 的 VisualSVN 插件。还有其他替代方案，例如 GIT ，也可以与 Visual Studio 合理集成。
没有“最佳”替代方案，但上述所有选项都效果很好。它们各有不同的优点和缺点，但它们都轻松胜过 VSS。
If you want to go the Microsoft route then TFS is the new VSS with a bunch of extra stuff.
I'm happy running Subversion with TortoiseSVN and the VisualSVN plugin for Visual Studio. There are other alternatives like GIT too with reasonable integration with Visual Studio.
There is no "best" alternative but all the above options works pretty well. They have their different strengths and weaknesses, but all of them easily outperforms VSS.
项目文件是如何损坏的？在任何源代码控制系统中，您要么必须获得文件的独占锁，要么接受可能合并文件的需要。
“腐败”或许并没有看上去那么严重。可能发生的情况是，您团队中的某人遇到了“合并冲突”，其中两个开发人员对同一行代码进行了不同的更改，并且只是忽略它。当发生这种情况时，SVN 客户端会将这些行并排放置在文件中，并带有指示每个更改所进行的修订版的标志。这肯定会阻止任何源代码或 XML 文件按照预期的方式进行解析。
要解决合并冲突，您必须通过选择要使用每行的两个版本中的哪一个来手动解决每个合并冲突。如果这种情况没有发生，您应该能够通过简单地首先使用版本控制来轻松找到未正确合并的人员并教育他们。忽略 TortoiseSVN 窗口中的红线是一件非常糟糕的事情。
在团队环境中使用版本控制可能需要一些时间来适应，但它是团队工作中非常必要的一部分。尝试实施以下一些开发策略：
将您的解决方案拆分为更多的项目。创建的每个新代码文件都需要更改项目文件，这可能会增加 PMS（痛苦合并综合症）的发生率，尤其是当您的应用程序只有一两个项目时。当新代码文件的创建速度随着产品的成熟而减慢时，您可以考虑将源代码合并回更少的程序集。
实施“持续集成”，也称为“自动构建”。像 TeamCity 这样的 CI 服务器可以坐在角落里的盒子上，等待团队成员签入代码。当发生这种情况时，它将检测签入，获取最新的源代码，并尝试构建它，还可以选择运行任何您想要的单元/集成测试、代码覆盖率、FxCop 规则检查等。如果未能完成其中任何一项，或者结果不令人满意，则构建会“损坏”，从损坏那一刻起直到构建再次成功，团队的工作就是通过纠正构建服务器的任何问题来“修复”构建发现。
How does the project file get corrupted? In any source control system, you either have to obtain exclusive locks on a file, or accept the need to possibly merge files.
The "corruption" may not be as bad as it seems. What is probably happening is that someone on your team is encountering a "merge conflict", where two developers have made different changes to the same line of code, and simply ignoring it. When that happens, the SVN client will place those lines side-by-side in the file with flags indicating which revision each change was made. That will definitely keep any source code or XML file from being parsed the way it was intended.
To resolve merge conflicts, you must go in and manually resolve each merge conflict, by selecting which of the two versions of each line you want to use. If this isn't happening, you should be able, by simple virtue of using version control in the first place, to easily find the person(s) who aren't merging properly and educate them. Ignoring red lines in your TortoiseSVN window is a Very Bad Thing.
Using version control can take some getting used to in a team environment, but it's a very necessary part of working as a team. Try implementing some of the following development policies:
Split up your solution into a few more projects. Every new code file created will require a change to the project file, which can increase occurrences of PMS (Painful Merge Syndrome), especially when your application has only one or two projects. When the creation of new code files slows down as the product matures, you can consider merging the source code back into fewer assemblies.
Implement "Continuous Integration", aka "Automated Builds". A CI server like TeamCity can sit around on a box in the corner and wait for team members to check in code. When that happens, it will detect the check-in, grab the latest source, and attempt to build it, optionally also running any unit/integration tests, code coverage, FxCop rule checks, etc that you want. If it fails to complete any of this, or the results are unsatisfactory, the build is "broken", and the team's job from the moment it breaks until the build succeeds again is to "fix" the build by correcting whatever problem the build server found.
您对该项目做了哪些改变？ SVN 和 VSS 都应该处理向项目中添加删除文件的操作，而不会引发冲突。我在更改其他项目设置（例如单击一次安装程序）以及更改 .proj 文件中的大块时遇到了问题。
一种可能的解决方案是为不同的安装配置创建单独的项目文件（但不要为每个使用代码的个人创建单独的项目，这会更糟）
What changes are you making to the project? SVN and VSS should both handle adding removing files to the project without throwing conflicts. I have seen issues when changing other project settings like click-once installers and such which change big chunks in the .proj file.
One possible solution is to create separate project files for different installation configurations (but do not create separate projects for each individual using the code, that will be even worse)