我们有一个包含数百个报告的大型ASP.NET项目。我们正在将所有SQL查询（针对Oracle数据库运行）移动到三个Web服务中。 Web服务按命令，选择和报告查询进行分类。我们必须使用SQL * Server后端将项目的子集部署到与Internet断开连接的多个位置。因此，拥有与数据库的所有连接和Web服务中的查询使应用程序易于管理，我们可以提取报告子集而不必修改代码。该项目使用Serena ChangeMan软件进行源代码管理。
问题是我们有几个程序员，他们都需要检查Web服务文件来处理他们的项目。我们刚刚实施了分支，但它正逐渐成为一场噩梦。我们有月度生产交付，有时应该进入月度构建的项目将持续到下个月。合并已成为一个手动过程。
我进行了互联网搜索，我很惊讶我找不到任何好的“最佳实践”网络服务架构白页。有许多大公司必须面对这些问题。
大多数大型开发组都使用分支吗？我确实读过Visual Studio Team System Database Edition可以提供标准代码，允许应用程序连接到不同的数据库。购买团队系统会是最好的方法吗？或者有谁知道我在哪里可以找到有助于我们解决这些问题的文档？
谢谢你， 洛里
答案 0 :(得分：2)
这个问题似乎完全独立于软件的目的。这里的问题是，您有一个小的，有限数量的文件，多个开发人员将每天使用这些文件。我没有使用Serena ChangeMan软件和TFS的经验，除了玩它。我确实有使用合并/提交模型的几个版本控制系统的经验： CVS 和 Subversion 。这些都是广泛使用的优秀的免费版本控制系统。
如果您不熟悉合并/提交模型，那么这里的想法是没有任何一个开发人员可以“签出”并锁定文件以进行更改。每个人都可以下载并更改任何文件。当需要将这些更改提交到源代码数据库时，如果其他开发人员对该文件进行了其他更改，则存储库软件将阻止提交。然后下载新版本，并且在大多数情况下，更改会自动与您的更改合并。您重新测试，然后您提交该版本。这个模型非常成功，而且非常可扩展。
说完所有这些之后，即使是合并/提交模型也无法解决由于许多开发人员对所述文件进行更改而导致少量文件的悲痛。我建议将您的功能分成更多的Web服务。也许您可以创建三组相关的Web服务，而不是三个单一的Web服务。我认为这一点，加上使用带有合并/提交的版本控制系统将解决您的问题。
CVS和Subversion服务器在Windows，Mac和Linux上运行。每个客户端都有许多客户端，可在许多操作系统上使用。其中包括独立客户端，Visual Studio插件和shell插件。另一个优点是CVS和Subversion都可以从命令行获得，这使脚本编写（想想自动构建）相当容易。
答案 1 :(得分：1)
为什么不将您的逻辑划分为可由每个开发人员检出的单个类文件？
答案 2 :(得分：0)
我们使用SOA，但我们也使用更加面向合并的SVN。也许考虑一个不同的源控制系统？