Warning: file_get_contents(/data/phpspider/zhask/data//catemap/2/linux/23.json): failed to open stream: No such file or directory in /data/phpspider/zhask/libs/function.php on line 167

Warning: Invalid argument supplied for foreach() in /data/phpspider/zhask/libs/tag.function.php on line 1116

Notice: Undefined index: in /data/phpspider/zhask/libs/function.php on line 180

Warning: array_chunk() expects parameter 1 to be array, null given in /data/phpspider/zhask/libs/function.php on line 181
Linux 为系统文件创建和使用Mercurial存储库_Linux_Mercurial - Fatal编程技术网

Linux 为系统文件创建和使用Mercurial存储库

Linux 为系统文件创建和使用Mercurial存储库,linux,mercurial,Linux,Mercurial,我已经在我的编程项目中成功地使用了相当长的一段时间,因此,让它处理我其余的版本控制需求也是一个合乎逻辑的步骤。这方面的第一步是让Mercurial处理我在Linux系统上手动修改的配置文件。不幸的是,我似乎遇到了一些障碍: Mercurial不存储文件元数据(所有权、权限、扩展属性) Mercurial不会处理不在存储库目录中的文件 我相信我已经找到了一个for(1),尽管它显然涉及到修改一个单独的和一点魔力的源代码 第二点似乎更棘手:出于各种原因,我不想将Mercurial存储库放在文件系统根

我已经在我的编程项目中成功地使用了相当长的一段时间,因此,让它处理我其余的版本控制需求也是一个合乎逻辑的步骤。这方面的第一步是让Mercurial处理我在Linux系统上手动修改的配置文件。不幸的是,我似乎遇到了一些障碍:

  • Mercurial不存储文件元数据(所有权、权限、扩展属性)

  • Mercurial不会处理不在存储库目录中的文件

  • 我相信我已经找到了一个for(1),尽管它显然涉及到修改一个单独的和一点魔力的源代码

    第二点似乎更棘手:出于各种原因,我不想将Mercurial存储库放在文件系统根目录(
    /
    )。不幸的是,Mercurial不会直接或通过符号链接处理位于存储库根目录之外的文件

    我可能会编写一个包装器脚本,使用或允许Mercurial访问根文件系统。我以前写过一个类似的脚本,但它绝不是透明的,而且在使用它时我不得不跳过很多障碍——正确地执行它会很棘手,特别是如果我想处理绝对文件路径的话

    在这一点上,我开始觉得我必须把很多本地解决方案堆在一起,以使Mercurial在这个用例中工作——可能太多了。我偶尔会碰到一些粗糙的边缘

    • 这个用例是否有一个完整的解决方案?允许
      hg
      透明地处理系统文件的Mercurial扩展或包装脚本

    • 或者,很不情愿地,是否有一个现代版本控制系统或其他版本控制解决方案可以做到这一点

    或者,也很不情愿地,有一个现代版本吗 控制系统或其他版本控制解决方案将在 盒子


    (类似于苹果的“时间机器”)不是VCS,但如果你想要的只是一个线性历史,它可能正是你所需要的。

    我终于用
    git
    找到了一个直截了当的解决方案。更具体地说,
    git
    允许工作目录(git术语中的工作树)远离存储库本身。在此之前,我要做的就是:

    • 在所需位置创建安全目录:

      # mkdir -p /root/git
      # chmod 700 /root/git
      
    • 在上一个目录中初始化
      git
      存储库:

      # cd /root/git
      # git init
      
    • 修改
      .git/config
      以包含
      core.worktree
      选项,方法是在
      [core]
      部分添加
      worktree=/etc

    • 正常使用git

      # git add /etc/hosts
      # git commit -m "..." -a
      

    +1这不是我需要的,但对于其他用例来说,它听起来非常有趣。对于个人配置文件(用户目录中的所有点文件),您通常会创建从预期位置到报告中实际文件的符号链接。。。你考虑过在这里这样做吗?@Ludovic:你会为
    /etc/fstab
    这样做吗?我确实不会,但这主要是因为我不会把它放在Mercurial的第一位。这些文件在我的计算机之间不太可能是相同的(除非你负责一个拥有所有相同PC的服务器场),并且在一台计算机的使用寿命内也不太可能有太大的变化(至少我不需要对其进行修订控制)。我的观点主要是讨论以另一种方式进行:与其将外部文件引入回购协议,不如将回购文件引入外部?但“不,我不能/不会”是一个正确的答案:)