请解决签出和锁定与更新和合并版本控制的争论
我已经使用源代码控制几年了（如果算上源代码安全年份），但我绝不是专家。我们目前使用的是旧版本的 Sourcegear Vault。我们的团队目前使用签出和锁定模型。我宁愿切换到更新和合并模型，但需要说服其他开发人员。
开发人员（不是我）设置为签出和锁定工作的原因是由于叛徒文件。我们公司与一家咨询公司合作来完成我们的大部分开发工作。几年前，早在我来这里之前，他们就已经设置了源代码管理来进行更新和合并。顾问们去检查，但遇到了合并错误。然后，他们选择在离线模式下工作几个月。当最终测试该项目时，出现了大量错误，并且发现代码库显着不同。几周的工作最终不得不重做。于是他们就去检查并上锁作为解决方案。
我不喜欢签出并锁定，因为这使得 2 人或更多人同时在同一个项目中工作变得非常困难。每当您添加任何类型的新文件或更改文件名时，源代码管理都会检查 .csproj 文件。这可以防止任何其他开发人员添加/重命名文件。
我考虑过只将 .csproj 文件设为可合并，但 Sourcegear 网站表示这是一个坏主意，因为 csproj 是 IDE 自动生成的，并且您不能保证两个不同的 VS 生成的文件会生成相同的代码。
我的朋友（另一位开发人员）告诉我，解决方案是立即签入您的项目。对我来说，问题在于我可能有一个无法构建的本地副本，并且可能需要一些时间才能构建。我可能需要几个小时才能开始构建工作，这意味着在此期间，没有其他人能够创建和重命名文件。
我反驳说，正确的解决方案是切换到可合并模型。我对“叛徒文件”问题的回答是，这是程序员纪律不严的问题，您不应该使用较弱的程序员选择来解决纪律不严的问题；相反，你应该采取行动来解决程序员纪律的缺乏。
那么谁是对的呢？签入-签出是对叛徒文件问题的合法答案吗？或者 .csproj 是否给多个开发人员带来了太大的麻烦？或者 Sourcegear 是错误的，应该可以设置 csproj 文件来更新和合并？
I've used source controls for a few years (if you count the Source Safe years), but am by no means an expert. We currently are using an older version of Sourcegear Vault. Our team currently uses a check out and lock model. I would rather switch to a update and merge model, but need to convince the other developers.
The reason the developers (not me) set up to work as check out and lock was due to renegade files. Our company works with a consulting firm to do much of our development work. Some years ago, long before my time here, they had the source control set up for update and merge. The consultants went to check in, but encountered a merge error. They then chose to work in a disconnected mode for months. When it was finally time to test the project, bugs galore appeared and it was discovered that the code bases were dramatically different. Weeks of work ended up having to be redone. So they went to check out and lock as the solution.
I don't like check out and lock, because it makes it very difficult for 2 or more people to work in the same project at the same time. Whenever you add a new file of any type or change a file's name, source control checks out the .csproj file. That prevents any other developers from adding/renaming files.
I considered making just the .csproj file as mergable, but the Sourcegear site says that this is a bad idea, because csproj is IDE auto-generated and that you cannot guarantee that two different VS generated files will produce the same code.
My friend (the other developer) tells me that the solution is to immediately check in your project. To me, the problem with this is that I may have a local copy that won't build and it could take time to get a build. It could be hours before I get the build working, which means that during that time, no one else would be able to create and rename files.
I counter that the correct solution is to switch to a mergable model. My answer to the "renegade files" issue is that it was an issue of poor programmer discipline and that you shouldn't use a weaker programmer choice as a fix for poor discipline; instead you should take action to fix the lack of programmer discipline.
So who's right? Is check in - check out a legitimate answer to the renegade file issue? Or does the .csproj issue far too big of a hassle for multiple developers? Or is Sourcegear wrong and that it should be ok to set the csproj file to update and merge?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
你们遇到的更新和合并问题的根源在于你们的团队和咨询团队之间缺乏沟通，以及咨询团队与你们的团队之间缺乏关于问题所在的沟通是，并且不一定是版本控制方法本身的问题。理想情况下，首先需要解决沟通问题。
我认为您对两种版本控制方法之间差异的技术分析是合理的，并且我同意更新/合并更好。但我认为真正的问题在于与您所在组中的人员的沟通，以及如何在版本控制的使用中变得明显，以及组中的人员是否同意/适应您的版本控制过程。我选择了。请注意，正如我所说，我自己的工作团队正在努力解决完全相同的问题，只是使用敏捷/SCRUM 而不是 VC。这很痛苦，很烦人，很令人沮丧，但（我认为）诀窍在于找出根本问题并解决它。
我认为这里的解决方案是确保（无论选择什么 VC 方法）与每个人进行良好的沟通，这是复杂的部分 - 你不仅需要让你的团队采用特定的 VC 技术，还需要咨询团队。如果咨询团队中的某人不确定如何执行合并操作，那么，请尝试培训他们。关键是保持沟通畅通、畅通，以便问题出现时能够得到解决。
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.
就我个人而言，我会避免在我的存储库中包含项目文件。但话又说回来，我永远不会将开发人员锁定在一种工具上。相反，我会使用生成项目文件/makefiles/其他内容的构建系统（CMake 是我这样做的风格）。
编辑：我认为锁定文件是解决症状，而不是疾病。如果这成为一种习惯，那么最终开发人员将无所事事。
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.
我曾与 40 多名开发人员组成的团队使用更新和合并模型合作过成功的项目。使这种方法发挥作用的是频繁的合并：独立工作人员不断更新（合并）存储库中的更改，并且每个人都经常合并他们的更改（一旦通过基本测试）。
频繁合并往往意味着每次合并都很小，这很有帮助。频繁测试，无论是在单独的代码库上还是每晚从存储库中检出，都会有很大帮助。
I have worked on successful projects with teams of 40+ developers using the update-and-merge model. The thing that makes this method work is frequent merges: the independent workers are continuously updating (merging down) changes from the repository, and everyone is frequently merging up their changes (as soon as they pass basic tests).
Merging frequently tends to mean that each merge is small, which helps a lot. Testing frequently, both on individual codebases and nightly checkouts from the repository, helps hugely.
我们使用的 Subversion 对高度并行环境中的任何文件没有签入/签出限制。我同意叛徒档案问题是一个纪律问题。不使用合并并不能解决根本问题，是什么阻止开发人员在其他人的更新上复制自己的“固定”代码副本？
合并是一个皮塔饼，但可以通过尽早并经常检查和更新本地副本来最大程度地减少合并。我同意你关于破坏签到的观点，应该避免这种情况。另一方面，使用签入的更改更新本地副本将迫使您正确合并更改，以便最终签入时一切顺利。
关于 .csproj 文件。它们只是文本，如果您花时间弄清楚文件的结构，它们确实是可合并的，还有需要维护的内部引用。
我不认为构建项目所需的任何文件都应该从版本控制中排除。如果项目的某些部分没有记录，如何可靠地重建或跟踪更改？
We are using subversion with no check-in/check-out restrictions on any files in a highly parallel environment. I agree that the renegade files issue is a matter of discipline. Not using merge doesn't solve the underlying problem, what's preventing the developer from copying their own "fixed" copy of code over other people's updates?
Merge is a pita, but that can be minimized by checking in and updating your local copy early and often. I agree with you regarding breaking checkins, they are to be avoided. Updating your local copy with checked in changes on the other hand will force you to merge your changes in properly so that when you finally check-in things go smoothly.
With regards to .csproj files. They are just text, they are indeed mergeable if you spend the time to figure out how the file is structured, there are internal references that need to be maintained.
I don't believe any files that are required to build a project should be excluded from version control. How can you reliably rebuild or trace changes if portions of the project aren't recorded?
IMO，诸如 .csproj 之类的项目文件不应该成为版本控制系统的一部分，因为它们并不是真正的源代码。
它们也几乎肯定是不可合并的。
IMO, project files such as .csproj should not be part of the versioning system, since they aren't source really.
They also almost certainly are not mergeable.
我是一家小公司的开发经理，只有3个程序员。
我们从事的项目有时需要几周的时间，并且我们采用大爆炸、震惊和敬畏的实施方式。这意味着我们有大量的数据库更改和程序更改必须在我们实施的当晚完美运行。我们检查一个程序，对其进行更改，然后将其搁置一边，因为在其他所有事情之前实施它会导致其他 20 件事情失败。我是来办理退房和上锁的。否则，另一个人可能会改变一些事情，而没有意识到该程序已经发生了巨大的变化。仅当您未对数据库进行更改或对不受源代码控制的其他系统进行更改时，合并才会有帮助。 （Microsoft CRM，基本上是任何可通过配置扩展的打包软件）
I am the development manager of a small company, only 3 programmers.
The projects we work on sometimes take weeks and we employ the big bang, shock and awe implementation style. This means that we have lots of database changes and program changes that have to work perfectly on the night that we implement. We checkout a program, change it and set it aside because implementing it before everything else will make 20 other things blow up. I am for check out and lock. Otherwise, another person might change a few things not realizing that program has had massive changes already. And the merge only helps if you haven't made database changes or changes to other systems not under source control. (Microsoft CRM, basically any packaged software that is extensible through configuration)