PQM needs to take over the world

Martin Pool mbp at sourcefrog.net
Thu Jul 19 03:08:43 BST 2007


On 7/18/07, Ian Clatworthy <ian.clatworthy at internode.on.net> wrote:
> Rob,
>
> Here's a good example of why I'd like you/us to promote PQM a bit more.
> Maybe it needs a bit more polish or doc first, but it really is an
> important part of the overall DVCS solution we're championing and teams
> are looking for.
>
> Ian C.
>
> -------- Original Message --------
> Subject: [Agile Teams, Open Software, Passionate Users] Comment:
> "Version Control: Plug-ins vs Toolkits"
> Date: Wed, 18 Jul 2007 20:57:53 +0000
> From: John Reese <ian.clatworthy at internode.on.net>
> Reply-To: nuclear_eclipse at leetcode.net <nuclear_eclipse at leetcode.net>
> To: ian.clatworthy at internode.on.net
>
> New comment on your post #23 "Version Control: Plug-ins vs Toolkits"
> Author : John Reese (IP: 129.21.38.100 , devxps.rit.edu)
> E-mail : nuclear_eclipse at leetcode.net
> URL    : http://leetcode.net
> Whois  : http://ws.arin.net/cgi-bin/whois.pl?queryinput=129.21.38.100
> Comment:
> I think the biggest thing holding me back from adopting a DRCS,
> specifically Bzr or Hg, is the lack of user administration features for
> using the system in a centralized fashion.  One of the greatest features
> of Subversion is that it can handle all of its own user authentication
> and security access, especially on a repository by repository basis.
> This means I don't need to rely on other tools to deal with user
> authentication and access, such as Apache's hideous .htpasswd scheme
> (for Hg), or setting up ssh accounts and keys for each project (for
> either).
>
> When I'm hosting my projects and repositories, especially in a
> shared-hosting environment (specifically Dreamhost), I don't like having
> to monkey around with a whole bunch of .htpasswd files, and I certainly
> don't like the prospect giving community members ssh access to my
> server, regardless of how well I know them.
>
> If one DRCS system could come out with it's own authentication mechanism
> akin to Subversion, and preferably integrate into Apache as well, I
> would switch over in a heartbeat.  But until then, Bzr, Hg, etc just
> create too many administration headaches for my taste, and they just
> aren't feasible.  I love the speed, flexibility, and offline abilities
> of Bzr and Hg, but I can't swallow the nightmare of giving access to my
> co-developers.  It's just too much of a pain in the ass.
>
> But still, good job on Bzr, it is still developing very nicely and
> quickly, and I look forward to the day I can switch over to it!  Cheers.

That is really interesting feedback.

I think this is actually a bit separate from but complimentary to pqm:
just wanting easy network authentication configured within Bazaar,
without depending on an external authenticated transport.  I think
this would be particularly useful on Windows were ssh is not commonly
installed by default and setting it up can be difficult.

It would be good to avoid developing our own authentication/integrity
layer, and we already have in paramiko a way to accept ssh connections
without depending on the server's ssh or usernames.  What I imagine is

 - an option to bzr serve to tell it to accept ssh connections -
either on 4155 if we can easily distinguish them, or another port -
probably not 22 by default
 - a file giving user names and the acceptable credentials for them -
either password or certificate
 - per-repository settings saying which users can get in

At least some of this is already prototyped in the test suite.  It
would be a great project if anyone wants to tackle it...


-- 
Martin



More information about the bazaar mailing list