一:按模块分配所有权
团队中的每个人在sourcesafe上保留自己的代码，但是自己是看不到未经授权其他人的代码和文档。到发布的时候有SCM把大家的代码那到一起编译生成一个版本。也就是说，项目的每一个工件，都是有所有权的，团队成员根据角色划分，每个角色对工件的所有权不同，最少的就是只拥有自己开发的部分的代码和文档。而项目经理或SCM等角色对全部工件有所有权。这样，除了少数几个人外，其他人不能拥有项目的所有代码和文档。
二：集体所有权
这种方式是极限编程中提倡的，团队中的任何人对任何代码都可以签入，签出。没有程序员对某一个特定模块单独负责。所有的模块对所有的人都是开放的。
显然，第一种方式有很多缺点：
1.不利于团队成员间的知识传播。代码没有经过其他人的眼睛，其质量就只能靠 这个模块的负责人了。也许你犯了错误或没有找到更好的实现方法，同样，别人碰到这样的问题， 可能还会重复你的老路。我曾经在几个人的代码中同时发现相同的明显错误，但是没有人认识到这个问题。
2.由于每个模块只由一个人或很少的几个人，那么一旦当这些人离开，由于没有人理解这个模块，工作交接会耗费更多的时间。为了把人变成可替换的零件所采取的过程，却在这里付出了更大的代价，无疑是一种讽刺。
3.底层模块对高层模块形成了更大的影响。或许是怕麻烦，编写高层模块的人经常在使用底层模块旧版本的基础上进行开发，有一天可能突然发现，更新过版本后自己的依赖于底层模块的代码已经无法编译了。底层模块如果发布的很频繁，要保持各个模块间的版本一致，实在是件很烦人的事。而且，每次发布都需要通知每个人。
4.对调试的影响，自己在调用别人的模块的代码中出了错误，到底是自己的错误呢？还是你所依赖的模块的错误？有时很难判断，因为你没有别人的模块的源代码，无法跟踪到内部查看究竟。要么把两部分代码拿到一起来跟踪（很痛苦），要么开始争论（更痛苦）。
5.发布的混乱。如果一个项目有20个模块，在开发初期每个模块平均两天发布一次，SCM可能会被烦死。而且把版本搞混的可能也更大。
第二种方式的优势也是显而易见的。
1.代码对所有人都是开放的，有利于开发人员之间互相取长补短，有利于代码风格的统一，有时会发现几个人写的代码在结构，甚至函数命名都是相同的，这不是一般的代码规范所能限定的。
2.每个人对每个模块都有一定程度的了解，当团队中的成员变动时，就有人能很快接替他的工作。
3.由于每个人每天来都取一次新版本，把各个模块版本一致问题减小到了最小。
4.不管是自己的还是别人的代码，出了问题，跟踪进去看个究竟，比胡乱猜测，询问别人模块的情况要顶用的多。
5.不需要有专门的人来控制版本，每天都有一个新版本，程序员手中的就是最新版本。
要说开放的源代码管理有没有缺点，有，那就是团队之间的磨合需要一段时间，开始的时候可能会产生一些混乱，但是渡过这段时期一般都会比较顺利的。
团队中的每个人在sourcesafe上保留自己的代码，但是自己是看不到未经授权其他人的代码和文档。到发布的时候有SCM把大家的代码那到一起编译生成一个版本。也就是说，项目的每一个工件，都是有所有权的，团队成员根据角色划分，每个角色对工件的所有权不同，最少的就是只拥有自己开发的部分的代码和文档。而项目经理或SCM等角色对全部工件有所有权。这样，除了少数几个人外，其他人不能拥有项目的所有代码和文档。
二：集体所有权
这种方式是极限编程中提倡的，团队中的任何人对任何代码都可以签入，签出。没有程序员对某一个特定模块单独负责。所有的模块对所有的人都是开放的。
显然，第一种方式有很多缺点：
1.不利于团队成员间的知识传播。代码没有经过其他人的眼睛，其质量就只能靠 这个模块的负责人了。也许你犯了错误或没有找到更好的实现方法，同样，别人碰到这样的问题， 可能还会重复你的老路。我曾经在几个人的代码中同时发现相同的明显错误，但是没有人认识到这个问题。
2.由于每个模块只由一个人或很少的几个人，那么一旦当这些人离开，由于没有人理解这个模块，工作交接会耗费更多的时间。为了把人变成可替换的零件所采取的过程，却在这里付出了更大的代价，无疑是一种讽刺。
3.底层模块对高层模块形成了更大的影响。或许是怕麻烦，编写高层模块的人经常在使用底层模块旧版本的基础上进行开发，有一天可能突然发现，更新过版本后自己的依赖于底层模块的代码已经无法编译了。底层模块如果发布的很频繁，要保持各个模块间的版本一致，实在是件很烦人的事。而且，每次发布都需要通知每个人。
4.对调试的影响，自己在调用别人的模块的代码中出了错误，到底是自己的错误呢？还是你所依赖的模块的错误？有时很难判断，因为你没有别人的模块的源代码，无法跟踪到内部查看究竟。要么把两部分代码拿到一起来跟踪（很痛苦），要么开始争论（更痛苦）。
5.发布的混乱。如果一个项目有20个模块，在开发初期每个模块平均两天发布一次，SCM可能会被烦死。而且把版本搞混的可能也更大。
第二种方式的优势也是显而易见的。
1.代码对所有人都是开放的，有利于开发人员之间互相取长补短，有利于代码风格的统一，有时会发现几个人写的代码在结构，甚至函数命名都是相同的，这不是一般的代码规范所能限定的。
2.每个人对每个模块都有一定程度的了解，当团队中的成员变动时，就有人能很快接替他的工作。
3.由于每个人每天来都取一次新版本，把各个模块版本一致问题减小到了最小。
4.不管是自己的还是别人的代码，出了问题，跟踪进去看个究竟，比胡乱猜测，询问别人模块的情况要顶用的多。
5.不需要有专门的人来控制版本，每天都有一个新版本，程序员手中的就是最新版本。
要说开放的源代码管理有没有缺点，有，那就是团队之间的磨合需要一段时间，开始的时候可能会产生一些混乱，但是渡过这段时期一般都会比较顺利的。
