【问题标题】:Versioning problem版本控制问题
【发布时间】:2009-12-02 21:50:40
【问题描述】:

人。我希望你能帮助我。

在我们的开发过程中,我们有一个基于 unix 的文件服务器,具有 SFTP 访问权限(我们称之为 A)。该服务器存储了大量我们正在处理的 xslt 文件。

问题是这些文件不在版本控制系统之下。所以你可以想象这个噩梦。我们无法在此服务器上设置存储库,我们只能对这些文件执行 create/read/update/delete 操作。

所以我们必须找到另一种方法。 还有另一台具有完全访问权限的服务器 (我们称之为 B)。是否可以使用后台逻辑在 B 上设置存储库,在每个存储库操作上执行与服务器 A 相关的下载/合并/上传操作?

还有两个问题:

  1. A 上的所有文件都位于同一个目录中,我们希望它们在服务器 B 上按文件夹层次结构进行结构化。
  2. A 上的文件可以由另一个团队更改。

我们正在使用 Subversion。但是也许可以用其他版本控制系统来实现rhs?

谢谢,Vova。

【问题讨论】:

    标签: svn versioning mirroring


    【解决方案1】:

    据我所知,没有版本控制系统会解决您的 #2 问题(A 上的文件可以由另一个团队更改)。您的其余要求可以通过 SVN 和一些简单的脚本来满足。这些可以是 DOS 批处理文件脚本、python、perl,任你选择。

    但是,如果您不能通过确保 A 上的文件从不被其他团队更改来解决您的 #2 问题,我认为您的要求是不可行的。所有团队都应处理服务器 B 上存储库中的文件。

    无论如何,只要我的 2 美分。 -道格

    【讨论】:

    • 这与存储库挂钩很可能会成功。但是你需要保证仓库总是领先的。
    【解决方案2】:

    您可以使用svnsync 来镜像存储库,或者您可以查看rsync 以从中进行更新,然后执行一些自定义任务。

    【讨论】:

    • 一台服务器是 SFTP,不是 Subversion,所以 svnsync 在这里帮不上忙
    • 呃桑德,请阅读问题。他在最后提到了 Subversion。
    • 他在服务器 B 上使用 Subversion。服务器 A 上没有版本控制
    • 是的,因此我建议它作为一种可能性的原因(即它可以安装)。你不是 OP;我不明白你如何判断它是否适合他;事实上,我不仅不知道怎么做,我知道你做不到。无论如何,不​​值得与您进一步讨论。
    猜你喜欢
    • 1970-01-01
    • 2010-11-03
    • 2013-05-26
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2021-08-29
    • 1970-01-01
    相关资源
    最近更新 更多