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