有没有 Visual C++ 的工具？或其他 IDE，这将允许超过 1 个程序员（在线）同时处理同一个项目？
那么有没有一种方法可以让我与远在 200 英里之外的程序员朋友共享整个环境，在一个共同的窗口中编辑、编译和执行我的代码？例如，我启动了一个在线会话，我的朋友加入了它，他的 IDE 将此会话的所有设置和项目/源文件与我的同步，因此我们可以通过网络实时处理同一个项目。
有可能吗？
So is there a way I can share whole environment, edit, compile and execute my code in one mutual window with my friend-programmer being 200 miles away from me ? For example, I start an online session, my friend joins it and his IDE synchronizes all settings and project/source files for this session with mine, so we can both work on the same project in real-time through net.
Is it even possible ?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
协作开发通常通过软件配置管理或版本控制系统来完成，例如 Subversion、PVCS、StarTeam、MKS、SourceSafe、CVS 或任何其他成本和复杂程度不同的选项。
通常的工作方式是，每个开发人员从存储库中检查代码和项目配置文件，在本地处理它们，然后从其他开发人员那里将更改提交到存储库。传统上，这是由开发人员锁定他们正在处理的文件来完成的，以便其他开发人员在“所有者”释放该文件之前无法提交更改。然而 Subversion 采用了不同的理念（尽管您仍然可以锁定文件）；它允许任意数量的开发人员同时对文件进行本地修改，然后使用三向合并将更改合并到存储库。如果沟通和项目控制良好，这种方法很有效，但如果两个开发人员以两种不同的方式解决同一问题，则最终可能会针对同一问题得到两次修复。它还可以很好地处理 VC++ 使用的 XML 格式的项目文件。任何 SCM 都支持分支和分支合并，因此个人开发人员可以在一个分支上工作，而不是在主干代码上进行混战，然后每个分支在经过验证和批准后可以定期与主干代码合并由团队领导。
然而，虽然这是协作开发的正常方法，尤其是在地理分布的情况下，但它并不完全是您所要求的。也就是说，我强烈建议您考虑更传统的工作方式；尤其是当开发人员位于截然不同的时区时。
另一方面，如果您本质上希望让两个开发人员同时处理相同的代码，如 “结对编程”，但是地理分布，那么我建议您只需使用某种远程访问工具，例如免费版本的 LogMeIn 除了允许远程和同时控制 PC 之外，它还具有 IM 类型通信，尽管您也可以将其与 Skype 等具有语音或视频连接的工具结合使用，以提高工作效率。
Collaborative development is normally done through a software configuration management or version control system such as Subversion, PVCS, StarTeam, MKS, SourceSafe, CVS or any number of other options of varying cost and sophistication.
The way this typically works is that each developer checks out the code and project configuration files from the repository, works on them locally and commits changes to the repository from where other developers. This is traditionally done by developers locking the files they are working on so that other developers cannot commit changes until the 'owner' has released the file. However Subversion takes a different philosophy (although you can still lock files); it allows any number of developers to make local modifications to a file simultaneously and then uses three-way merging to merge changes to the repository. This works well if communication and project control is good, but if two developers fix the same problem in two different ways, you could end up with two fixes for the same problem. It also works fairly well with the XML format project files that VC++ uses. Any SCM will support branching and branch merging, so rather than have a free-for-all on the trunk code, individual developers may work on a branch, and then each branch might be periodically merged with the trunk code when it is verified and approved by the team leader.
However while this is the normal method of collaborative development, especially when geographically distributed, it is not exactly what you asked for. That said, I strongly suggest that you consider the more conventional way of working; especially if the developers are in vastly different time-zones.
If on the other hand you essentially want to have two developers working together on the same code at the same time, as in "pair programming", but geographically distributed, then I suggest that you simply use some sort to remote access tool such as the free version of LogMeIn which as well as allowing remote and simultaneous control of a PC, it has IM type communication, although you might also use it in conjunction with something like Skype with a voice or video connection to be somewhat more productive.
我不明白这怎么可能运作良好。想必您必须拥有自己的中间目录来存放输出文件。如果您都将目标文件写入相同的文件夹，那么这将是一场灾难。
你会如何同步？你们中的一个人 A 开始编译，但 B 人继续编辑。 A 的编译使用 B 正在编辑的文件的哪个版本？ B 会因为 A 正在编译而被禁止编辑吗？
这需要工具供应商的大力支持，我无法想象这种情况会发生，因为没有人愿意使用它。
I can't see how this could possibly work well. Presumably you'd have to have your own intermediate directories where your output files went. If you both wrote object files to the same folders then that would be a disaster.
How would you synchronize? One of you, person A, starts to compile but person B carries on editing. What version of the file that B is editing does A's compile use? Would B be blocked from editing just because A was compiling?
This would require significant support from tool vendors and I can't imagine that ever happening because nobody would want to use it.