不签入应该没有事吧.

严格划分模块，各小组开发自己的模块，小组之内每个人在签入之前必须保证代码是可以编译通过的。 其实保证签入的代码编译通过，是很低的要求，如果还实现不了，可以通过一些处罚制度来强制保证签入之前编译通过

另外建一个工程文件和解决方案`~只把与自己有关的加进来就可以了，不过前提是这些代码不能对未加入的部分产生依赖`~~

恩，可以不用签入阿。 如果他还没签入，就撤销签出阿。 适时看吧。

如果团队在一个VSS工程中做项目，那么就必须保证团队中每个人签入的代码是必须编译通过的，否则当其他人获新时将影响他人的开发。这种事情正如网友玉开所说一定要杜绝，虽然有解决方法，但是会耽误时间，相信没有任何一个团队愿意在这方面浪费时间。 有些网友们提供了一些在没有发生之前的解决方法，即撤销签出。如果已经发生了如何弥补呢，肯定是比较麻烦些，但是还是可以解决的，方法如下： 1、如果错误不是很大，容易修改，那么就请产生此错误文件的同志将代码改正正确（即编译可以通过），签入后团队所有人获新，如果有牵连文件需要一并保证正确并都获新。 （1）优点：一步到位，不需要让产生错误的同志编写已经写过的代码。 （2）缺点：团队中每个人（只要获新了错误文件的人）几乎都不能进行调试，需要等待此人将文件修改正确后重新获新才能进行调试，耽误了大家的时间。 （3）适用：必须是举手之劳的错误才选用此方法去修改，如果越修改错误越多，那么放弃此方法，选择第2种方法。 2、注释错误代码，以及注释后还有牵连的代码一并注释掉并签入，直到注释的能够顺利编译通过为止，然后签入，使团队所有人获新文件，产生错误代码的同志将注释的文件及牵连的文件全补签出，取消注释并修改错误，直到正确后方再签入。 （1）优点：注释代码消耗的时间短，并不会耽误团队人开发，而只需要消耗产生错误的同志的时间，并且大家不用等待他改正错误，而且以前的算法、思路和代码都还在（无论正确还是错误）不需要完全重头来过。 （2）缺点：产生错误的同志可能需要修改原来的代码。另外如果有连锁反应，即需要注释非产生错误的人开发的文件，比如错误是基类而被注释了（也许以前正确而如今被产生错误的同志修改了），很多人都用到的类，那么就会产生连锁反应，这种方法就不适用了。 （3）适用：大部分情况，然而如果注释出现了连锁反应，那么就需要使用第3种方法，不过连锁反应情况不多见，因为他人编写的文件一般在团队开发中是不允许另外的人修改的。 3、使用VSS提供的版本恢复功能，VSS保存以前对此文件的所有操作，除非此文件被彻底从VSS中删除了，否则此文件的每次签入操作都有一个历史版本保留，而团队中对所有文件的获新也只是获取最近一次被签入的文件，因此可以恢复以前的历史文件为最新文件。 （1）优点：方便快捷，恢复后出错的可能性很小。 （2）缺点：如果代码与其他无牵连则还好，如果有牵连则都需要被恢复到历史版本，可能本身正确的文件也受到牵连需要被恢复为历史版本，可能会影响到他人的工作进度，他人有可能需要重写一些代码，以前的一些算法、思路和代码需要重头在思考、设计和编写。 （3）适用：一般不要使用此方法，除非错误很难被找寻或者牵连的代码众多时才选择此方法（可能找问题比修改所用的时间还要多，还不如从某一个时期开始重来更快些） 请酌情选择上述解决方法，切忌不要如楼主所说将错误文件排除到工程之外，因为此文件毕竟是需要的文件不能排除，除非你确定不再需要此文件时才删除或排除。最常用、最快捷、最有效的方法就是第2种方法了。 祝您好运，早日解决问题！

如果只是不加载别人的文件，你可以加载后在排除项目外即可了。 不过，不建议把项目组成员的内容排除在项目外，你应该建议他们编译通过后，在提交，每天上班之前大家都获取一下最新的，时间久了，就养成这样好的习惯了。

排除后只要不签入项目文件就没有问题 其实问题的关键还是个人习惯，那就是签入前，一定要获取整个项目的最新版本，然后整体编译，编译通不过的版本禁止签入