重新组织目录树而不弄乱 SVN 日期
我有一个 svn 树，多年来已经变得混乱。它包含许多多年未修改的文件和目录......上次活动的日期是一个主要线索。
如果我“svn 在某处重命名 foodir/foodir”，我会得到所需的结果，但具有新的日期和历史记录。因此，这些文件看起来比实际情况更新鲜。
使用 cvs，我只需“mv”服务器上的相关文件或目录即可获得重新组织树的所需结果，而无需创建历史记录或弄乱日期。用svn可以完成同样的操作吗？
我知道“svn propset svn:date”： 使用旧日期/时间进行 SVN 提交 但这既尴尬又只是部分解决方案。
I have an svn tree that over years has become messy. It contains many files and directories that have not been modified in many years... the date of last activity is a major clue.
If I "svn rename foodir somewhere/foodir" I get the desired result, but with new dates and history. The files thus look more fresh than they really are.
With cvs I could just "mv" the relevant files or directories on the server get the desired result of reorganizing the tree without creating history or messing with dates. Can the same operation be done with svn?
I am aware of "svn propset svn:date":
SVN commit with old date/time
But that's both awkward and only a partial solution.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
对于您的情况，“手动”更改存储库中的数据并不是一个好方法。 SCM 工具旨在保留“历史”时间线。您可能需要这段历史来挖掘为什么半年前某些二进制文件运行良好而现在却损坏了。
我没有看到 svn move 中有任何不好的地方 - 历史记录将显示该移动和所有以前的历史记录。这样你就会知道每个文件/目录来自哪里。
但如果你使用 cvs，我可以同意你的观点。在 cvs 中，与 svn 相比，不支持文件移动，如果不维护目录则不支持历史记录。
cvs 和 svn 的其他一些问题正是旨在解决这些问题。
至于会改变的日期 - 如果你有数千个文件，那么谁关心日期 - 只需查看 svn 日志即可。
Changing data "by hand" in repository is not good approach in your case. SCM tools are designed to preserve "history" timeline. You may need this history to dig why half year ago some binary worked fine and now is broken.
I don't see any bad in
svn move- the history will show the move and all previous history. Thus you will know were each file/directory came from.But if you was using cvs I could agree with you. In cvs, in contrast to svn, move of files is not supported, history if directory is not maintained.
Exactly these problem of cvs and some others svn is aimed to solve.
As for dates which will change - if you have thousands of file, than who care about date - just look to svn log.