为外部承包商清理 Mercurial 存储库

发布于 2024-11-17 22:13:06 字数 231 浏览 1 评论 0原文

我有一个包含一些敏感文件和目录的活动项目。我想聘请外部承包商来做一些简单的 UI 工作。但是,我不希望承包商有权访问某些目录和文件。我的项目在 Bitbucket 上的 Mercurial 中。

清理项目并让他有权提交更改的最佳方法是什么?我考虑过分叉到一个新的存储库,但我担心删除我不希望他访问的目录。

如何删除它们以便它们不显示原始变更集?如何合并他的存储库而不删除我的主存储库中的那些目录?叉子是可行的方法吗?

I have an active project with some sensitive files and directories. I want to hire an external contractor to do some simple UI work. However, I don't want the contractor to have access to some directories and files. My project is in mercurial on Bitbucket.

What is the best way to clean up the project and give him access to commit his changes? I thought about forking into a new repository, but I am worried about removing directories I don't want him to have access to.

How to I remove them so they don't appear the original changesets? How to I merge his repo back without it removing those directories in my main repository? Is a fork the way to go?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

じ违心 2024-11-24 22:13:06

当然,存储库需要访问其整个历史记录,以便自我检查其完整性。我不知道如何有选择地隐藏部分存储库(有 ACL 扩展,但它仅用于写访问)。

在您的情况下,我将

  1. 创建一个新的存储库,其中所有敏感信息都已被剥离(使用 转换扩展 用于该任务)。
  2. 然后我会让外部人员使用该存储库。
  3. 一旦他的工作完成,将他的存储库拉入原始存储库的克隆中(使用 -f 强制拉出不相关的存储库),并
  4. rebase 他的第一个变更集及其所有子变更集到原始存储库的头部。
  5. 最后,将变基后的头推送到原始存储库。

对于步骤 3 到 5,您不必等到外部开发人员完成。对其存储库的中间状态进行变基也是可能的。

然而,这是一个理论想法......人们必须看看它在实践中的表现如何。

替代方案:如果您经常有外部承包商不应该看到您的代码的某些部分,我会支持@Anton 的评论以设置与多个存储库相关的权限。

Naturally a repository needs access to its whole history in order to self-check its integrity. I don't know of a way to selectively hide parts of the repository (there's the ACL extension, but it is for write access only).

In your case, I would

  1. create a new repository where all sensitive information has been stripped off (use the convert extension for that task).
  2. Then I would let the external guy work with that repository.
  3. Once his work is finsihed, pull his repository into a clone of the original one (using -f to force pulling of an unrelated repository), and
  4. rebase his first changeset and all its children onto a head of your original repository.
  5. Finally, push the rebased head to the original repository.

For steps 3 to 5 you don't necessarily have to wait until the external developer is done. Rebasing intermediate states of his repository is also possible.

Yet, it's an theoretical idea .. one has to see how it performs in practice.

Alternative: In case you frequently have external contractors who shouldn't see some parts of your code, I would second @Anton's comment to setup permission related multiple repositories.

狂之美人 2024-11-24 22:13:06

有多种方法可以做到这一点:

  1. 使用子存储库
  2. 使用多个存储库
  3. ???

无论如何,您需要重组和拆分现有的存储库,因此,如果您有很多人从事该项目,这将造成严重破坏,他们都需要停止工作,同步他们的工作,销毁他们的本地克隆,并在之后克隆新的副本。重组。

使用多个存储库的一种方法是执行以下操作:

  1. 创建存储库的 2 个额外克隆(保留一个以备后备,如果一切失败,您可以随时返回)
  2. 运行 hg Convert< 所需的第一个克隆/code> 命令删除承包商不应访问的所有零碎内容
  3. 然后修复该存储库,使其自行运行。您可能必须更改代码,以便为不存在但打算在构建之前注入到项目中的任何内容提供挂钩和事件
  4. 然后您需要在另一个克隆上运行 hg Convert 以删除所有内容现在出现在第一个。
  5. 然后,您从第一个(承包商)存储库拉入第二个(私有)存储库,合并并进行必要的修复,以便代码仍然按预期工作

您现在拥有的是两个存储库:

  1. 承包商存储库,仅包含位您想要公开
  2. 一个私有存储库,该存储库已从承包商存储库中拉取并合并,并包含所有其他零碎内容

从现在开始,每当承包商将工作推送到其存储库时,您都需要从中拉取并放入私有存储库然后合并。

您的存储库将如下所示:

Contractor:  ---97---98---99---100---102---103---104

                                               M                 M
Private:     ---91---92---93---94---95---96---101---105---106---107
                                             /                 /
                                            /                 /
                       ---97---98---99---100---102---103---104

上面带有 M 的两个变更集是合并变更集,它将承包商提供的代码合并到您的私有存储库中。

请注意,您也必须将代码提交到承包商存储库,以处理和修复代码中的错误,但您可以保留所有私有位。

There are multiple ways to do this:

  1. Using sub-repositories
  2. Using multiple repositories
  3. ???

Regardless, you need to restructure and split your existing repository, so this will create havoc if you have lots of people working on this project, they will all need to stop working, synchronize their work, destroy their local clones and clone down fresh copies after the restructuring.

One way using multiple repositories would be that you do the following:

  1. Make 2 extra clones of the repository (keep one around for fallback if everything fails, you can always go back)
  2. The first clone you need to run the hg convert command on to get rid of all the bits and pieces your contractor should not access
  3. Then you fix that repository so that it works by itself. You might have to change code to provide hooks and events for anything not present but which you intend to inject into the project before you build
  4. Then you need to run hg convert on the other clone to get rid of everything now present in the first.
  5. Then you pull from the first (contractor) repository into the second (private) repository, merge, and do necessary fix-ups so that the code still works as intended

What you have now is two repositories:

  1. Contractor-repository, with only the bits you want to expose
  2. A private repository, that has pulled and merged from the contractor-repository, and contains all the other bits and pieces

From now on, whenever the contractor has pushed work to his repository, you need to pull from it and into the private repository and then merge.

Your repositories would look like this:

Contractor:  ---97---98---99---100---102---103---104

                                               M                 M
Private:     ---91---92---93---94---95---96---101---105---106---107
                                             /                 /
                                            /                 /
                       ---97---98---99---100---102---103---104

The two changesets with M above are merge-changesets that merge contractor-supplied code into your private repository.

Note that you too would have to commit code to the contractor-repository, to work on and fix bugs in the code there, but all the private bits you can keep private.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文