3

我已经使用源代码控制几年了（如果算上 Source Safe 年数），但我绝不是专家。我们目前使用的是旧版本的 Sourcegear Vault。我们的团队目前使用签出和锁定模型。我宁愿切换到更新和合并模型，但需要说服其他开发人员。

开发人员（不是我）设置为签出和锁定的原因是由于文件叛徒。我们公司与一家咨询公司合作完成我们的大部分开发工作。几年前，早在我来到这里之前，他们就为更新和合并设置了源代码控制。顾问去check in，却遇到了合并错误。然后他们选择在断开连接的模式下工作数月。当终于到了测试项目的时候，出现了大量的错误，并且发现代码库有很大的不同。数周的工作最终不得不重做。所以他们去检查并锁定作为解决方案。

我不喜欢签出和锁定，因为这让 2 个人或更多人很难同时在同一个项目中工作。每当您添加任何类型的新文件或更改文件名时，源代码管理都会检查 .csproj 文件。这可以防止任何其他开发人员添加/重命名文件。

我考虑将.csproj文件设为可合并，但 Sourcegear 网站说这是一个坏主意，因为 csproj 是 IDE 自动生成的，并且您不能保证两个不同的 VS 生成的文件会生成相同的代码。

我的朋友（另一位开发人员）告诉我，解决方案是立即签入您的项目。对我来说，问题在于我可能有一个无法构建的本地副本，并且可能需要一些时间来构建。我可能需要几个小时才能使构建工作，这意味着在此期间，没有其他人能够创建和重命名文件。

我反驳说正确的解决方案是切换到可合并模型。我对“叛徒文件”问题的回答是，这是程序员纪律不佳的问题，您不应该使用较弱的程序员选择来解决纪律不佳的问题。相反，您应该采取行动来解决程序员缺乏纪律的问题。

那么谁是对的呢？签入 - 签出叛徒文件问题的合法答案吗？还是这个.csproj问题对多个开发人员来说太麻烦了？还是 Sourcegear 错了，应该可以将csproj文件设置为更新和合并？

4

6 回答 6

5

The problem with update and merge that you guys ran into was rooted in a lack of communication between your group and the consulting group, and a lack of communication from the consulting group to your group as to what the problem was, and not necessarily a problem with the version control method itself. Ideally, the communication problem would need to be resolved first.

I think your technical analysis of the differences between the two version control methodologies is sound, and I agree that update/merge is better. But I think the real problem is in the communication to the people in your group(s), and how that becomes apparent in the use of version control, and whether the people in the groups are onboard/comfortable with the version control process you've selected. Note that as I say this, my own group at work is struggling through the exact same thing, only with Agile/SCRUM instead of VC. It's painful, it's annoying, it's frustrating, but the trick (I think) is in identifying the root problem and fixing it.

I think the solution here is in making sure that (whatever VC method is chosen) is communicated well to everyone, and that's the complicated part - you have to get not just your team on board with a particular VC technique, but also the consulting team. If someone on the consulting team isn't sure of how to perform a merge operation, well, try to train them. The key is to keep the communication open and clear so that problems can be resolved when they appear.

于 2009-09-16T16:59:19.063 回答
2

我曾使用更新和合并模型与 40 多名开发人员团队一起完成了成功的项目。使这种方法有效的原因是频繁的合并：独立的工作人员不断更新（合并）存储库中的更改，每个人都经常合并他们的更改（只要他们通过基本测试）。

经常合并往往意味着每次合并都很小，这很有帮助。频繁地测试，无论是在单个代码库上还是从存储库中进行夜间检查，都会有很大帮助。

于 2009-09-16T17:04:05.733 回答
2
  1. Use a proper source control system (svn, mercurial, git, ...)
  2. If you are going to do a lot of branching, don't use anything less recent than svn 1.6. I'm guessing mercurial/git would be an even better solution, but I don't have too much hands-on-experience using those yet.
  3. If people constantly are working on the same parts of the system, consider the system design. It indicates that each unit has too much responsibility.
  4. Never, ever accept people to offline for more than a day or so. Exceptions to this rule should be extremely rare.
  5. Talk to each other. Let the other developers know what your are working on.

Personally I would avoid having project files in my repository. But then again, I would never ever lock developers to one tool. Instead I would use a build system that generated project files/makefiles/whatever (CMake is my flavor for doing this).

EDIT: I think locking files is fixing the symptoms, not the disease. You will end up having developers doing nothing if this becomes a habit.

于 2009-09-16T17:00:12.343 回答
0

我们在高度并行的环境中使用对任何文件没有签入/签出限制的颠覆。我同意叛徒文件问题是一个纪律问题。不使用合并并不能解决根本问题，是什么阻止了开发人员复制他们自己的“固定”代码副本而不是其他人的更新？

合并是一个皮塔饼，但可以通过尽早并经常签入和更新您的本地副本来最小化。我同意你关于打破签到的观点，它们是应该避免的。另一方面，使用签入更改更新本地副本将迫使您正确合并更改，以便在您最终签入时一切顺利。

关于 .csproj 文件。它们只是文本，如果您花时间弄清楚文件的结构，它们确实是可合并的，有需要维护的内部引用。

我认为构建项目所需的任何文件都不应该从版本控制中排除。如果没有记录项目的某些部分，您如何可靠地重建或跟踪更改？

于 2009-09-16T16:49:48.070 回答
0

我是一家小公司的开发经理，只有3个程序员。我们从事的项目有时需要数周时间，我们采用大爆炸、震惊和敬畏的实施方式。这意味着我们有很多数据库更改和程序更改必须在我们实施的晚上完美运行。我们检查一个程序，更改它并将其放在一边，因为在其他所有事情之前实施它会使其他 20 件事情崩溃。我是为了退房和锁定。否则，另一个人可能会改变一些事情，而没有意识到程序已经发生了巨大的变化。只有在您没有对数据库进行更改或对其他不受源代码控制的系统进行更改时，合并才会有所帮助。（Microsoft CRM，基本上是任何可通过配置扩展的打包软件）

于 2010-12-23T22:08:38.323 回答
-1

IMO，.csproj 等项目文件不应成为版本控制系统的一部分，因为它们实际上不是源代码。

它们也几乎可以肯定是不可合并的。

于 2009-09-16T16:42:32.627 回答