Is it possible to allow push but disallow pull?

[Angel Ezquerra]

Tom, thanks for your answers and comments. My comments below.

On Tue, Feb 21, 2012 at 11:47 AM, Tom Anderson
<tom.anderson at timgroup.com> wrote:
> On 21/02/12 07:54, Angel Ezquerra Moreu wrote:
>
> So my questions are:
> - Is it possible to limit (or forbid) who can pull from a repo, while
> still letting them push to that very same repo?
>
>
> You should be able to write a preoutgoing hook which exits with a nonzero
> status, which will block pulls:
>
> http://www.selenic.com/mercurial/hgrc.5.html#hooks

That is a good idea, thanks. I was expecting to find out about an
hgweb configuration setting but that should work equally well.

> - Does this workflow make sense?
>
> IMHO, no. The problem is that if someone pushes changegroup C to the build
> repo, then nobody else can push their work until they've merged it with C.
> They can't merge with C until they can pull it, and they can't pull it until
> it's been through the build process. That severely limits the rate at which
> people can push, which is not a good thing.
>

That is true (and something that we are aware of). The build & test
procedure would take from 5 to 10 minutes. It is not a big team so
they are ok with having a single build & test procedure running at a
time. They'd rather have to wait their turn to push than having a
person dedicated to resolving conflicts and merging their development
branches. We'll have to devise a way to notify people when the build
is done though.

> - Has someone done something like this? What were your experiences?
>
> A team at my previous company did something similar with Git (as i have
> mentioned here before - sorry if i'm boring anyone!). They used Gerrit:
>
> http://code.google.com/p/gerrit/
>
> And followed its workflow. Basically, everyone pushed from their local repo
> into a per-user mirror repo on the server (which they could pull from, but
> nobody else could), where code review happened, and from where merges were
> made into the trunk by a duly approved merge-person (which i think, in
> practice, was everyone on the team). Commits on the trunk were built and
> tested by CI before being made available to users. This partially solved the
> problem of the build delay blocking pushes, because users can still push at
> any time; however, it still delayed merges, which is the real problem.

That is a good alternative. I'll propose it to them. However they may
balk at the need to have CI test things before pushing them to the
release server.

> - Any alternatives?
>
> A couple of things spring to mind.
>
> One is to use this approach, but allow pulls from the dirty repo. Developers
> who just want to stay up to date with the trunk can pull from the clean
> repo, and know that they're only pulling tested code. Developers who intend
> to push to the dirty repo must pull from that, so they can merge with it,
> but it's only at that point that their work will meet untested code from
> other developers.

The problem with that is that they'd rather fix their commits by
modifying the history rather than by creating new commit bugfixes (to
keep their history a bit cleaner). Still that is also a very good
alternative. In fact if the "obsolete" concept ever makes it into
mercurial this could be _the_ way to do this sort of thing.

> Another is to push some of the testing into the push process itself. You may
> not be able to run a complete build and test in a push hook, but i postulate
> that you might be able to do enough to catch some kinds of errors, and so
> keep really broken code out of even the dirty repo. I work in Java, and my
> scheme for doing it there (which i researched but never put into practice)
> was to use Eclipse running in headless mode to incrementally compile pushed
> code, which should take less than ten seconds, and then run the unit tests,
> which should take tens of seconds. This would mean that pushing to the dirty
> repo took less than a minute; slower than usual, but fast enough to be
> fairly unobtrusive. You can then use the longer clean - build - unit test -
> integration test - deploy - system test cycle as the gatekeeper to the clean
> repo.

We'll take all your comments into account. Thanks a lot!

Angel