Is it possible to allow push but disallow pull?

[Tom Anderson]

On 21/02/12 18:40, Stephen Morton wrote:
> Since you asked for alternatives, so how about workflow... It assumes 
> that designers are able to test their own work before pushing so that 
> in general failure is not that common. It also assumes a general real 
> commitment (as opposed to just a token commitment) to not break the build.
>
>     * Designers push to the build repo. There would be no blocking of
>       pushes. Just keep adding to the tip.
>     * Integrators (ideally automated, not real people) run the tests
>       on the tipmost changeset of the build repo. If the tests pass,
>       the test repo is pushed to the official repo.
>           o If they fail:
>                 + A nasty email is sent to the designer CCing
>                   /everybody else/ telling them that they broke the
>                   build and that they'd better commit a fix fast.
>                 + The integrator tool goes down the test repo history
>                   of un-pushed commits (if there is one) looking for
>                   the last working version that it can push to the
>                   official repo.
>           o Once a fix is committed, it will be the tipmost version
>             and the whole history can be pushed to the official repo.
>     * Yes, this means there are some intermediate changesets in the
>       official history that fail tests. So what?
>     * Yes, in a pathological case of people continuously breaking the
>       build you could never push the tip of the build to official and
>       some intermediate "good" changes could not be pushed. That's
>       what I was talking about when I talked about a real commitment
>       to not breaking the build. If that commitment is there, this
>       problem does not exist.
>
> The issue that I see with this and any similar workflow is that there 
> is some implicit merging happening. If you're pulling from one place 
> and pushing to somewhere else which may have different code then you 
> will have problems. I'd say you'd have to solve them with a model 
> something like this:
>
>     * Designers pull and push from the build repo. Testers pull from
>       the official repo. (The integrator tool pulls from the build repo.)
>     * There must be a hard rule that at a certain frequency
>       (personally, I'd say no more than 30 mins) the tip of the build
>       repo must be able to be pushed to the official repo. If not,
>       there is hell to pay. (Again, that commitment thing.)
>
> I expect that this suggestion will be extremely unpopular with some 
> people. But I actually think it sounds pretty good.
>

I think it sounds good. I think it also sounds like the standard 
workflow in use by 99.992% of software shops today: developers work in a 
development repository, pulling and pushing (or updating and committing 
in CVS/Svn-land) without interference from integration processes; CI 
tests the tip of the development repository; QA and other consumers of 
development's work on revisions that have passed testing by CI (whether 
by pushing to another repo, the setting of a bookmark, or some 
out-of-band method). I'd be surprised if that many people objected to it!

tom

-- 

Tom Anderson | Developer | +44 20 7826 4312 | timgroup.com 
<http://timgroup.com/>

STATEMENT OF CONFIDENTIALITY: The information contained in this 
electronic message and any attachments to this message are intended for 
the exclusive use of the addressee(s) and may contain confidential or 
privileged information. If you are not the intended recipient, please 
notify Natalie Hall at TIM Group at either +44 20 7826 4308 or 
natalie.hall at timgroup.com and destroy all copies of this message and any 
attachments.

TIM Group is the trading name for YouDevise Limited. YouDevise Limited 
is registered in England, No. 3331176. Registered office: 3 Copthall 
Avenue, London, EC2R 7BH.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurial-scm.org/pipermail/mercurial/attachments/20120223/bddbea4f/attachment-0002.html>