Problems with hg push over SSH

[Giorgos Keramidas]

On 2007-08-29 11:02, Paul Sargent <psarge at gmail.com> wrote:
>On 8/29/07, Dustin Sallings <dustin at spy.net> wrote:
>[a whole lot of scary chaos that boils down to this]
>> If it's *your* project, you can tell people where they can get your
>> code.  If it's someone else's project, they might want a bundle or
>> patchbomb or something.  If you could host your own branch on a web
>> server, it's often better.
>
> I'm fast coming to the conclusion that the randomly connected
> distributed model just doesn't scale, but because the tool is
> distributed you have the choice of topology that works best for you.

Yes, that's exactly the point of not ennforcing a particular topology of
workspaces on everyone.  Each project can choose its own.

> Maybe that'll be a tree, like Linus uses for the Linux Kernel. Maybe
> (shock, horror) it'll be a centralised repository. It'll probably end
> up being some hybrid. The main thing is to actually think about it,
> because if you let it grow naturally it'll be chaos.
>
> "With great power comes great responsibility"

Agreed, 100% :)

>> The only way I could see this being possible is by having a central
>> repo where changes are checked into once in a while.
>
> I think most projects would have a master repository of some kind.
> That's either going to be controlled by the head developer, or be
> unmanned, which is my preference, but probably with limited push
> rights so that changes have to go through 'trusted' developers.

Sun's Teamware documentation describes how Sun has been using a
distributed SCM for a while now.  They use the notion of "gates",
i.e. special workspaces whose caretaker is called "gatekeeper".

It is the responsibility of the gatekeeper to control who gets
to push to a repository.  Pulling from any "gate" is free, but to
be able to push changes to the gate you have to abide by the rules
set by the gatekeeper.

Other useful ideas described in the Teamware documentation are:

  * Integration workspaces

  * Reparenting

  * An interesting topology of workspaces called "a train".

Maybe some of the experience of Sun with Teamware can be useful in
designing use cases for Mercurial too? :-)

References:
***********

[1] Sun Microsystems. "Sun WorkShop TeamWare User's Guide".
    http://docs.sun.com/app/docs/doc/805-4949/
[2] Sun Microsystems. "SPARCworks/TeamWare & ProWorks/TeamWare Solutions
    Guide".  http://docs.sun.com/app/docs/doc/802-3637