是否有任何代理可以表现得像“虚拟”代理？ SVN服务器连接到远程存储库？
我有一个远程 SVN 存储库，但我无权管理。该存储库服务器除了常规 SVN 操作外没有任何额外功能，并且不包含任何（有用的）SVN 挂钩。我有兴趣为远程存储库设置某种本地代理（不确定如何调用它）（例如，当有人将更改提交到本地“虚拟”存储库时，本地服务器必须提交更改为远程代理），如果这样的代理可以支持 SVN 挂钩，那么我就可以配置我的本地（或 LAN）一组 SVN 挂钩，那真是太棒了。
所以我正在寻找的是，就像一个常规代理服务器，但其行为像一个“虚拟”SVN 服务器。有可能吗（特别是对于 Windows）？
提前致谢。
PS 抱歉，可能没有那么清楚的解释。
I have a remote SVN repository that I have no permissions to administrate. That repository server has no extra features except of regular SVN operations, and it does not contain any (useful) SVN hooks. I'm interested in setting up of some kind of a local proxy (not sure how exactly it may be called) to the remote repository (e.g., when someone commits the changes to the local "virtual" repository, the local server must commit the changes to the remote one), and it would be really and really great if such a proxy could support SVN hooks so I could configure my local (or LAN) set of SVN hooks.
So what I'm looking for is, let's say, just like a regular proxy server but that behaves like a "virtual" SVN server. Is it possible at all (especially for Windows)?
Thanks in advance.
P.S. Sorry for probably not so clear explanation.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
对于我来说，这个问题至少有两个已知的解决方案。
第一个是使用从属端 SVNMasterURI 指令对远程主服务器和本地从属 SVN 服务器进行详细配置。据我目前了解（但我还没有尝试过）考虑建议的解决方案，这个解决方案可能有一些困难：使用 svnsync （它可能会导致与主存储库的绝对同步 - 这并不总是很好）；主服务器特定配置，但这并不总是可能是因为没有管理主存储库的权限；一些可能的问题< /a> 从属存储库工作；据我了解 SVNMasterURI 指令的范围，将整个从属服务器（而不是单个从属存储库）全部提交给主服务器。
第二种可能更简单的解决方案是使用安装了 hgsubversion 扩展的 Mercurial，配置共享本地 Mercurial 存储库，并启用
commit.autopush挂钩。不幸的是，这个解决方案对我来说至少有几个问题：我们的开发团队不会很乐意学习 Mercurial 只是为了使用构建/电子邮件/测试挂钩（这些更改太激进了，当然+这并不意味着拒绝掌握SVN思想）；据我了解，从 Mercurial 存储库修订号与主 Subversion 存储库修订号不匹配，这让我们感到困惑。There are at least two known for me solutions of this problem.
The first is a detailed configuration of the remote master and the local slave SVN-servers using the slave-side
SVNMasterURIdirective. As far as I understand at the moment (but I still have not tried it yet) considering a proposed solution, this solution may have some difficulties: using svnsync (it may cause absolute synchronization with the master repository - that is not always fine); master server specific configuration, but that is not always possible because of no permissions to administrate the master repository; some possible problems of the slave repository work; as far as I understand the scope ofSVNMasterURIdirective, total submission of entire slave server (not a single slave repository) to the master one.The second, probably simplier, solution is using of Mercurial with the hgsubversion extension installed, configuring the shared local Mercurial repository, and enabling the
commit.autopushhook. Unfortunately, this solution has at least a few problems to me: our development team won't be very happy to learn Mercurial just to use build/email/test hooks (these changes are too radical, sure + that does not mean rejection of the master SVN ideology); as far as I understand, slave Mercurial repository revision numbers mismatch the master Subversion repository revision numbers leaving us confused.