查看完整版本: 修订版本号太多怎么办

修订版本号太多怎么办

最近发现SVN从版本库CHECKOUT\EXPORT\UPDATE越来越慢,检查发现版本库以前没人控制,大家频繁修改并单个文件提交,造成修订版本号已经接近12万了,不知道速度变慢是否是这个原因
如果是的话,有没有什么办法可以转储一些太老的修订,比如将第100001个修订版本作为新的初始版本

有同样的问题。。。
不过我们的项目刚开始，才10几个版本，就有这样的情况，单个文件上传的情况。

我也想知道，现在刚刚开始部署SVN，很关注svn可能出现的问题，期待高人指点::em54::

是呀，开发的习惯不好，导致数据太多

这个问题的确值得关注，应该要注意。

规定开发人员每天提交一次代码，或一个功能完成后提交一次代码。

楼上的办法不能从根本上解决问题，我们使用一年左右，还没有发现慢的问题，关注此问题的解决

重新建库吧。肯定是你的建库策略有问题。

比较好的办法就是一个较大的项目建一个库，这样既容易控制版本号，又可以方便日后结项备份。

这个问题的确值得关注，应该要注意。

我认为这个问题不一定是开发人员的操作习惯问题，对开发库的操作就是非常频繁的，svn只是记录修改内容，不会在每个修订版中保存全部内容。
有三种情况会导致该问题：
1、配置库有比较大的文件，在制定配置策略时需要定义好配置项和适当限制上传文件的大小，一般文档，代码什么的都不会太大的，不要将工具、太大的学习资料等放在配置库里，这些都是不会或很少变更的，应该用其他方式共享。
2、配置库的确文件比较多，随着项目的进展，有很多基线、版本形成（这种情况配置库大小不会增加太多，因为svn对于branch/tag只是做链接，并不占用磁盘空间，但是如果check out到工作空间就大了），针对这种情况在checkout时可以选定目录，而不是checkout整个配置库。
3、项目比较大，针对这种情况在做配置策略时就应该考虑到，可以将公共模块单独建一个配置库，提高复用性，如果其他模块还是很大，可以考虑每个模块单独建库，如果不愿单独建库，可以用多库模式，在设计配置库前需要弄清楚系统架构、项目的任务划分情况和访问权限等。如果设计的合理，可以不checkout整个项目，而是有针对性的，因为每个人关注的内容不一样的。

[[i] 本帖最后由 千寻 于 2008-7-10 09:41 编辑 [/i]]

因为SVN只记录修订,而要export一个文件,SVN是否是要将该文件所有的修订合并起来才能组装出文件的最新版本啊,所以我觉得速度慢就是因为修订号太多了,大量文件被太多次的修改,SVN记录了太多次的修改.
所以,除了新创建一个版本库,将现有的最新版本import进去重新从1号修订版本开始外,有没有其他办法可以消除修订号太多引起的速度减慢的问题啊

版主对问题已经解释的很深刻了，我想说几点：
1、配置库的目录结构一定要在前期规划，这样一来方便我们进行配置管理工作，二来方便我们进行进行权限控制（每个人所关注的内容是不一样的）；
2、对配置项的存放要求，一些二进制而又比较大的文件可以考虑共享方式（比如版本记录等）；