[Bioperl-l] SVN and ...Re: Perltidy

[George Hartzell]

Nathan S. Haigh writes:
 > [...]
 > Sounds like George might know what he's doing! 

Hey, I've been looking for a Marketing Director.  Want a job?

 > I have a question about
 > setting up svn access. I believe access can be done in several ways,
 > over webdav, over ssh and probably others too. Do you have any knowledge
 > about the benefits of one over the other? I suppose I'm thinking of what
 > to implement to allow anonymous read access for users and authenticated
 > access for developers.

There are two and a half ways to talk to the repository:

  - You can put it behind a web server (e.g. apache) and get at it
    using http/https.  Authentication and authorization happen using
    the normal web server tricks, so as long as you don't do anything
    silly (e.g. don't use basic auth, stick with mod_auth_digest),
    even http connections won't send passwords in the clear.  You can
    define users in .htpassword files or use any of the fancier setup
    (e.g. sql databases, etc...).

  - You can talk to it via subversion's simple server, svnserve.
    There are two ways you usually talk to svnserve (neither of which
    send passwords in the clear):

      * directly, using a URL like
          svn:/svn.example.com/repo/proj/trunk
        when you do this the client either talks directly to a copy of
        svnserve running as a daemon, or possibly to something like
        inetd that'll start an svnserve as necessary.

        In this case, you define authen. and author. info in an
        svnserve.conf file.

      * indirectly, using a URL like
          svn+ssh://svn.example.com/repo/proj/trunk/
        in which case you make an ssh connection to the server machine
        (and authenticate via ssh mechanisms, anything other than a
        key-pair will drive you nuts with repeated password requests)
        and then an svnserve process is started up for you in "tunnel
        mode".  Access control is coarse grained an via OS level  access
        permisions. 

        Generally in this case you need to give out shell accounts to
        everyone involved, or (tsk, tsk) have them use a common
        account.  There's a cute trick in the svn book that shows how
        to use a shared ssh account but still have all of the changes
        in the repo keep track of the real user.  I've never tried
        it.... 

   - If you're on the same machine as the repo, you can do this
     simple:
        file:///path/to/repo/proj/trunk

The biggest deciding factor is how you want to manage your users and
whether you're already messing around with a web server.  I've
generally worked in small group and everyone's had ssh access, but
I've set it up the other ways too.

You can even access via multiple paths.  The only trick is that the
repository needs to be writable by whoever's committing, and if
they're running svnserve themselves (file: or svn+ssh:) and things
aren't set up right (all the dirs in the repo need to be group
writable and have the magic bit set so that any new stuff created is
also writable, users umasks and group membership need to be aligned)
then things go fubar.  Google's your friend here, and each of the
OS's/distro's has a standard hack for making this work, usually
involving a wrapper app that takes care of things.

Feel free to ask any particular questions.

Phew,

g.