subversion server variant and other cleanups

[jmpp@…]

The attached patch provides a server variant for the subversion port, doing two things:

• placeholder instructions to startup the subversion server upon system start: these are only placeholders for the moment as I'm not incredibly acquainted with the subversion server as of yet, so I'll let Daniel decide what's best to put here (including "nothing" as a possibility and removing the placeholders altogether);
• subversion user creation, so that the server can run as a registered system user; unfortunately there's no --with-subversion-user=<user> in subversion's autoconf to hardwire server credentials at package configuration time, akin to mysql's equivalent option, so I'm still not sure if this addition is desireable either. I'll again let Daniel decide and/or improve.

The patch also cleans up a couple orthogonal things in the Portfile: reorders pre-configure, configure.args, post-configure and build.target instructions in a more logical flow and corrects some typos in the ui_warn instruction in the mac_os_x_server_mod_dav_svn variant (missing ) character and 's/-/_/g').

Please improve and consider for inclusion.

-jmpp

[jmpp@…]

Portfile patch

[danielluke (Daniel J. Luke)]

subversion repositories are usually served up either with apache2 (and the mod_dav_svn variant) or svn+ssh - neither of which could utilize a launchd startup item (svnserve _could_, but it's not a normal setup, and I think it's best to let people handle that themselves).

... unless you were thinking of something else?

I'll go ahead and commit your ui_warn change.

[jmpp@…]

I was precisely thinking about running the svn server directly through svnserve(1). Such setup does need a dedicated system user just like Apache, postfix and other daemons. But arguably svn over http is by far the most common setup, indeed. What about renaming the variant to "svnserve" and adding an appropriate description to be more explicit about its intent?. Lastly, you didn't like my pre-configure, configure.args, post-configure and build.target reordering? No changes in Portfile logic there, just a saner flow I believe.

-jmpp

[danielluke (Daniel J. Luke)]

I think there's a contrib script that people use to run svnserve, but I'm not sure. I haven't had any requests from people actually wanting to set up svnserve for as long as I've been maintaining the port.

A +svnserve variant would probably be fine (are you thinking of writing one with the startupitmes stuff filled out?)

I didn't do the re-ordering because It doesn't seem necessary (the current ordering leaves the configure-related reinplaces next to each other and below the configure.args and build.target which are more likely to change between releases).

[jmpp@…]

I was thinking about writing the variant complete with startupitem actions (start, stop and restart) but then realized I'm not experienced enough to write them. Therefore was hoping you could lend a hand ;-) For insance, is it recommended to start up the server with threads (-T) or regular fork(2)? I don't know the best answer to that and many other questions.

About the reordering, I just thought it's more logical to see all configure related stuff first and then build stuff, even though that has no bearing on what the Portfile does at runtime.

-jmpp

[danielluke (Daniel J. Luke)]

As for the ordering, I figured that was your intent, but it's currently ordered to be easy for me to update the port :)

As for the startupitem, since I don't run svnserve (and again, haven't had anyone who uses the port ask for a svnserve variant) I'm not sure which way to run it is best. I would be looking at documentation/other ports systems to see what they do (and I think, for marginal benefit).

[jmpp@…]

As for the ordering, the maintainer should definitely have the upperhand ;-) I'll later contribute appropriate startupitem actions if I do find them. Thanks for the feedback anyhow! ;-)

-jmpp

[(none)]

Milestone Port Enhancements deleted