几年前,我们的软件开发团队部署了 TortoiseSVN 1.4.3,现在我们正在考虑将客户端升级到最新的 1.6.x 版本。我原本希望这次升级是透明的,附加功能和修改是在客户端进行的。在大多数情况下,这是正确的,除了一个非常重要的功能——合并。当我尝试将功能分支合并回卡车时,我收到一个令人震惊的“合并跟踪不支持错误”。
以下是一些值得注意的事实:
-
首次创建存储库时(在我加入之前),它是通过 TortoiseSVN 客户端本身。我们本身没有“SVN 服务器守护进程”,而是存储库文件夹/数据库驻留在共享文件夹上,可以通过 file:/// 从我们的工作站计算机访问该共享文件夹。这实际上让我大开眼界。我一直以为我们正在与某个 SVN 服务器守护进程进行对话。
-
除了读取/写入共享本身的能力之外,我们无法访问托管 SVN 共享的底层计算机。我什至不知道机器正在运行什么操作系统。选择此共享服务器是因为我们的 IT 团队每晚都会备份其驱动器。
-
老实说,我们确实不需要合并跟踪功能,尽管拥有它会很好。目前,能够在 1.4.3 存储库上使用 1.6.x TortoiseSVN 客户端并使其合并(无跟踪)而不会出现错误就足够了。
如何在不访问存储库所在的底层计算机的情况下将客户端创建的 1.4.3 存储库升级到 1.6.x 兼容版本?
我希望 TortoiseSVN 客户端本身有能力做到这一点,但事实似乎并非如此。
我是否会被迫将整个存储库复制到本地驱动器,运行一些 SVN 命令在本地升级存储库,然后将存储库复制回共享点?如果是这样,如果我们无法同时升级所有客户端,这样做是否会破坏与 1.4.3 客户端的兼容性?
注意
根据给出的一些答案,该问题已完全改写。
A few years ago, TortoiseSVN 1.4.3 was deployed to our software development team and we are now looking at upgrading the client to the latest 1.6.x version. I had hoped this upgrade would be transparent with the additional features and modifications being client-side. For the most part, this was true except for a very important feature -- merging. When I try to merge a feature branch back into truck I get a show-stopping "Merge tracking not supported error."
Here are some facts worth noting:
-
When the repository was first created (before I was on board), it was created via the TortoiseSVN client itself. We do not have an 'SVN server daemon' per se, rather the repository folders/database resides on a share folder that is accessible from our workstation machines via file:///. This was actually an eyeopener for me; I had always thought there was some SVN server daemon we were talking to.
-
We do not have any access to the underlying machine hosting the SVN share other than the ability to read/write to the share itself. I don't even know what OS the machine is running on. This share server was chosen because its drives are backed up nightly by our IT group.
-
In all honesty, we really don't need the merge tracking feature although it would be nice to have. For the time being, it would be sufficient to be able to use a 1.6.x TortoiseSVN client on the 1.4.3 repository and have it merge (sans tracking) without error.
How does one upgrade a client-created 1.4.3 repository to a 1.6.x compatible version without access to the underlying machine the repository resides on?
I was hoping the TortoiseSVN client itself had the ability to do this, but that does not appear to be the case.
Will I be forced to copy the entire repositoryover to my local drive, run some SVN commands to upgrade the repository locally and then copy the repository back to the share point? If so, will doing this break any compatibility with the 1.4.3 clients in case we can't upgrade them all at the same time?
NOTE
The question has been completely reworded in light of some of the answers given.
发布评论
评论(2)
您将需要执行
svnadmin -upgrade
来转换存储库格式。只需确保先备份存储库...以防万一。大多数情况下,1.4.x 客户端应该能够与 1.6.x 服务器通信。当然,1.6.x 服务器具有 1.4.x 客户端不支持的功能,因此这些功能将不可用。
编辑:
您是否通过 TortoiseSVN 创建存储库并不重要。一切都以同样的方式发生。您需要下载 Subversion 命令行工具才能使用 svnadmin。我肯定会首先将存储库复制到您的本地驱动器,以便您可以尝试升级。如果不升级该存储库,您将被迫放弃新功能。我认为您可以在不影响现有 1.4.x 客户端的情况下升级存储库,但在替换服务器上存储库的生产副本之前进行测试总是没有坏处的。
You will need to do an
svnadmin -upgrade
to convert the repository format. Just make sure you backup the repository first...just in case.For the most part 1.4.x clients should be able to talk to a 1.6.x server. Of course the 1.6.x server has features that the 1.4.x clients do not support so those features will be unavailable.
Edit:
It does not really matter that you created the repository via TortoiseSVN. It all happens the same way. You will need to download the Subversion command line tools to be able to use svnadmin. I would definitely copy the repository to your local drive first so you can experiment with the upgrade. Without upgrading that repository you will be forced to forfeit the new features. I think you will be okay upgrading the repository without affecting the existing 1.4.x clients, but it never hurts to test that out before you replace the production copy of the repository on the server.
基于兼容性矩阵,看起来兼容性不应该成为问题。但是,正如您已经经历过的那样,可能会出现特定功能缺失的情况。
有关升级,请参阅:
Stack Overflow 问题如何将 SVN 1.4.4 (r25188) 升级到 SVN 1.6
svnadmin升级
(命令行命令)
可能是时候重新评估 SVN 的情况了。我无法想象无法访问机器的情况。我会要求 IT 人员在进行备份后进行升级(也进行您自己的 SVN 备份),或者授予您对计算机的访问权限。
至于使用文件// SVN 访问:哎呀。我会立即更改它,以便可以通过 HTTPS 访问它。我无法想象只能在本地网络上访问它 - 尽管我认为 VPN在那种情况下会起作用。
Based on a compatibility matrix, it looks like compatibility should not be an issue. However, specific missing functionality will likely occur as you already experienced.
For upgrades, see:
Stack Overflow question How to upgrade SVN 1.4.4 (r25188) to SVN 1.6
svnadmin upgrade
(command-line command)It's probably time to re-evaluate the SVN situation. I can't imagine not having access to the machine. I would demand/request that either the IT people do the upgrade after doing a backup (do your own SVN backup as well) or grant you access to the machine.
As for using file// SVN access: Yikes. I would change that right away, also so it is available via HTTPS. I can't imagine only being able to access it on your local network - although I suppose VPN would work in that case.