我最近的任务是在我们的开发系统上实施版本控制。我通过执行以下操作使用 TortoiseSVN 创建了一个 SVN 存储库：
导入代码后，我是否认为不再需要存储在那里的代码？其他机器上的工作副本似乎没有任何提交更改了该代码，只有 svn 存储库。
我熟悉 SVN 不简单存储原始代码，而是存储差异的概念。出于这个原因，我的问题是：备份自己的 SVN 存储库文件夹是否足以作为此代码的备份策略？
作为预防措施，我们每个月都会手动备份工作机器上的代码，我正在考虑编写一个预定的批处理文件来每天将存储库 svndump 到远程驱动器。如果我做后者，并且假设我们丢失了存储库服务器和工作机器，我们能否从这个 daly svndump 中恢复代码？
希望这是有道理的；提前致谢。
备份 SVN 存储库服务器就足够了。要记住的一件事是，如果工作机器出现故障，您将丢失对工作机器所做的任何配置，例如服务器配置、系统变量等，因此请确保将这些配置记录在案。如果您在虚拟化环境中运行，您可以备份机器映像，这将真正加快您的恢复时间。
至于 svndump，这正是它的用途。您可以创建一个新的存储库并加载转储文件，您将拥有工作代码和所需的一切。
我建议使用转储文件进行恢复的试运行，这样您就可以确信您正在正确地创建转储文件，并且当发生实际紧急情况时您不会试图弄清楚如何恢复转储文件.
将代码导入存储库后，应删除原始“源”。它没有链接到存储库（除非您执行了就地导入），并且您不希望人们遇到它认为他们可以/应该继续使用它。既然您的东西在 SVN 中，那么该存储库就是您代码的规范来源。
制作存储库数据库文件夹的简单副本（或使用您选择的企业备份工具进行备份）作为备份可能还不够。如果您的副本是在另一个操作正在进行时执行的，您最终可能会得到一个处于奇怪状态的存储库备份。今天这并不像BDB基于存储库在地球上漫游时那样大，但它需要成为一个考虑因素。
改为使用svndump或制作您的副本以进行备份。svnadmin hotcopy有关详细信息，请参阅手册。
您仍然需要备份您的访问控制配置（除非您使用 1.8 中的新功能将其存储在存储库本身中）和您的挂钩脚本。那些不是由svndumpor处理的svnadmin hotcopy。
请记住，如果您正在执行每日备份并且您的存储库中有很多流失，那么您仍然很容易受到影响。如果您在午夜进行备份，而硬盘驱动器在晚上 11 点发生磁头碰撞，您就失去了一整天的工作。出于这个原因，一些存储库管理员在白天更频繁地进行增量转储或热拷贝，或者在每次提交后更频繁地进行真正的偏执。
如果您需要恢复存储库，则在开发人员工作站（或您的“工作机器”）上备份工作副本是没有用的，因为这些工作副本不保存存储库历史记录。如果它能让你感觉更好就去做，但是工作副本在 Subversion 中被认为是一次性的。这样做的唯一原因是备份人们尚未提交的更改（在这种情况下，他们为什么要推迟？），或者在需要备份后加快恢复工作的过程（通过不迫使他们执行新的结帐）。