On Thu, Mar 13, 2008 at 07:29:55PM -0600, Modulok wrote:
Is there a compelling reason for placing subversion and web-server
data in /usr/local and not somewhere else? I was thinking of keeping
all user accounts (human and daemon alike) in one place like,
/home/www and /home/svn and so forth.
Before I break convention, I just thought I'd see if placing said
files in /usr/local was just a tradition or if there was another
reason for it.
Break the convention!
Where apache or any other web server looks for its "home" is down to
*your* apache config. Different vhosts can look wherever they like for
their own homes and you can put them wherever you like - no need for
them to be in the same place at all. So one vhost could look in
/home/project1 and another in /home/project2/Web, for example. You
could keep the default server in /usr/local/www and then you get the
files the port installs by default, but still control where *your* data
goes.
I don't know how tied subversion is to it's home in /usr/local but I
would hope "not at all". /home/cvs has been the home of my CVS
repositories for a long time and if I switched VCS I'd certainly want to
follow a pattern like that (certainly for anything that follows a
CVS-like model, which subversion does. Something like Hg might be
another matter, but then I'd be looking at putting repositories in
project-specific locations).
I dislike the notion of putting project-specific data under /usr/local.
Config files and the like are easy to control, but large trees should be
able to live wherever I want them to live.
One can usually work around any issue that arise, and if you hit
trouble, just mail back here :-)
--Alex
PS You said "demons" and I'd certainly draw a line between a demon like,
say, postfix or bind which has a system-role and ones like apache,
subversion or a database which have a project-role. Not sure it's a
very firm line though - plenty of grey area. For me, if it's manageable
with a simple CVSed config file or ten, then it can stay in /usr/local.
If it breeds data, then it belongs somewhere else.
_______________________________________________
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
