我经营着一个由 8 人开发团队和几个经理组成的小办公室。我们正在考虑转向硬件设置，我们有一个强大的服务器运行多个 VirtualBox VM - 一个用于 Samba 文件共享充当 DC，另一个用于开发的 LAMP 盒，另一个用于 IE 测试......等等......可能总共 4 或 5 个 VM。两个关键的是运行我们网络的 Samba 盒子，然后是我们大部分开发工作在其上进行的 dev LAMP 盒子。
这种设置吸引我的原因是因为我喜欢能够在必要时在一夜之间备份所有 VM 的想法 -如果我们有一个准系统 VirtualBox 主机，恢复应该是快速而轻松的。
我很欣赏备份虚拟机需要关闭电源，但我认为这不会成为阻碍。可能我们决定在核心主机操作系统上运行 Samba，因此无需关闭它（我们将整理数据的 rsync）。
所以我只是在寻找关于这种“适用于一切的虚拟机”方法的一些意见。这对企业来说是正常的吗？与物理盒子相比，这是否有任何明显的问题或无法实现的事情？有没有人尝试过这个并遇到任何重大问题，或者它的效果很好？
任何意见非常感谢。
亲切的问候，
詹姆士。
我最近通过后向端口将我在 Debian Etch 上的 Subversion 包更新到 1.5.1。我已经完成了我认为所有适当的步骤，但是当我尝试合并时，我一生都无法克服以下错误消息：
'.' 不支持对合并信息的检索
这 '。' 并不重要，因为无论我是通过 SSH 连接到服务器还是通过 Windows 使用 TortoiseSVN，我都会收到相同的消息。
我将带您逐步完成升级和测试的过程：
Subversion的更新
将以下行添加到 /etc/apt/sources.list：
deb http://www.backports.org/debian etch-backports 主要贡献非免费
然后跑了
apt-get -s -t etch-backports 安装颠覆
检查了subversion安装的版本
通过运行完成此操作
svnadmin --version
并得到以下输出：
svnadmin，版本 1.5.1 (r32289)
编译于 2008 年 12 月 11 日，18:10:14
也使用检查客户端
svn --version
并得到以下
svn，版本 1.5.1 (r32289)
编译于 2008 年 12 月 11 日，18:10:14
好的，到目前为止一切看起来都不错。
现在我只需要升级存储库。经过大量研究，最简单的方法似乎是转储存储库，然后再次加载它。所以这就是我所做的：
svnadmin 转储 /var/svn/repo > repo.dump
rm -aR /var/svn/repo/*
svnadmin 创建 /var/svn/repo
svnadmin load < repo.dump
所有这一切似乎都运行良好。然后我通过查看/var/svn/repo/db/format的内容来检查存储库是否已升级： …