问题描述
是否可以用某种形式的钩子来拒绝将影响存储库中特定命名分支的变更集?
我们有一个托管项目，只要他们位于自己的命名分支中，我们希望允许任何开发人员将其更改推送到我们的存储库中.这使我们可以在同一个存储库中管理单个buildbot和一个共享沙箱(通过保持分支分离).我们希望阻止任何局外人尝试写入默认分支的尝试(我们将在内部合并其分支).
我们正在考虑使用pretxnchangegroup挂钩，但这有2个问题:
1)用户可以使用任何用户名推送更改；我们基本上只有一个http-auth通过要求任何用户名或密码实际连接到存储库来保护存储库，但是它不会检查提交中的用户名以确保它们与用于推送的帐户匹配.
2)可以说，用户做了正确的事并在分支中发展，但随后他们在默认分支上进行了最后一次提交. hg push失败.开发人员此时会做什么以解决他们的问题?
有什么想法吗?
是的，您可以使用pretxnchangegroup轻松地完成此操作.我将在shell中进行操作，但是如果您在python中进行操作，它将是进程内的(因此速度更快).
将类似这样的内容设置为您的pretxnchangegroup:
#!/bin/sh
for thenode in $(hg log -r $HG_NODE:tip --template '{node}\n') ; do
if [ $(hg id --branch -r $thenode) = "default" ] ; then
echo Commits to default branch are not allowed -- bad changeset $thenode
exit 1
fi
done
这可以确保所有到达的变更集都不在分支默认"上.
关于关注点1:如果您要在apache之后运行，则可以访问常规的CGI变量，因此，如果要尝试执行此操作，则可以检查$ REMOTE_USER以确保其与分支名称匹配. /p>
关于关注点2:如果用户看到消息表明他们正在推送无效的变更集，那么他们只需要使用push -r推送其余的变更集，他们便可以在以后默认情况下剥离或修改其变更集.
最后，您是否考虑过为自动构建/主分支仅创建一个单独的克隆?让每个人都进入暂存仓库，并且当他/他对它们满意时，只让buildmaster将已批准的变更集从暂存中拉入到自动构建中吗?您将获得与现在相同的工作流程(等待构建器合并)，但是麻烦就少了.
Is it possible to write some manner of hook in mercurial that will reject changesets that effect a specific named branch in a repository?
We have a managed project and would like to allow any developers to push their changes to our repository so long as they are in their own named branch. This allows us to manage a single buildbot and a shared sandbox in the same repository (by keeping branches separate). We'd like to block any attempts to write to the default branch from outsiders (we would, internally, merge their branches over).
We're looking at using the pretxnchangegroup hook, but this has 2 concerns:
1) A user can push changes using any username; we basically only have an http-auth protecting the repository by requiring any username or password to actually connect to the repo, but it doesn't check the usernames in the commit to make sure they match the account used to push.
2) Lets say a user has done right and developed in a branch, but then they do one last commit on the default branch. The hg push fails. What does the developer do at this point to fix their push?
Any thoughts?
Yeah, you can do this pretty easily with the pretxnchangegroup like you figured. I'll do it in shell, but it'd be in-process (and thus faster) if you do it in python.
Set up something like this as your pretxnchangegroup:
#!/bin/sh
for thenode in $(hg log -r $HG_NODE:tip --template '{node}\n') ; do
if [ $(hg id --branch -r $thenode) = "default" ] ; then
echo Commits to default branch are not allowed -- bad changeset $thenode
exit 1
fi
done
That makes sure that none of the arriving changesets are on branch "default".
Regarding concern 1: If you're running behind apache you'll have access to the usual CGI variables, so you can check $REMOTE_USER to make sure it matches the branch name if that's something you want to try to enforce.
Regarding concern 2: If a user sees the message that they're pushing an invalid changeset, then they'll just have to push the rest of them using push -r and they can strip or modify their changeset on default later.
Lastly, have you considered just having a separate clone for the auto-builds / main branch? Let everyone push into the staging repo, and let only the buildmaster pull approved changesets from staging into auto-build when s/he is happy with them? You get the same workflow you have now (waiting for a builder to merge), but it's much less hassle.
这篇关于阻止对单个Mercurial存储库中特定分支的写访问的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！