I noticed that the Subversion book by default recommends non-standard
/usr/local repository location. You might consider suggesting a better
alternative that's being discussed and considered for the upcoming FHS 2.3+
The start of the proposal is included.
Jari
http://bugs.freestandards.org/cgi-bin/bugzilla/show_bug.cgi?id=16
Anthony Towns <aj <AT> humbug.org.au
This'll probably create/restart a flamewar, but here's a patch to add
/srv. It's fairly minimal, and doesn't go out of its way to declare
existing practice like /var/www or /var/cvs evil, it just makes a new
place for them which is specifically _not_ evil.
I can't seem to find a copy of the last proposal, but I believe this also
differs from that in that it specifically doesn't specify any hierarchy
under /srv. The rationale is that exactly how you want to organise your
data is _highly_ site specific. Debian.org boxes, eg, use directories
like /org/bugs.debian.org/ to store all the data that goes towards
http://bugs.debian.org/, including most of the configuration. Many
single purpose sites will probably want to just split it up by program
(/srv/apache, /srv/cvs). Others might want to do it by organisation
(/srv/foocorp, /srv/physics, /srv/cs3245/group1). This is quite legitimate
and distribution and application vendors should expect it.
Why is this at the root level? Because it really is fundamentally different
to the other hierarchies:
/etc - configuration data
/usr - programs
/var - data generated by and for programs
/home - personal data for individual users
/srv - data generated by users for the services the system offers
Why does this need to be specified at all? Because vendors need some
place to offer default suggestions for where CVS repositories or FTP
sites or web sites should be put, and users could really do with some
useful guidelines too (well, at least, I felt that way a year or so ago --
and ended up using /var/local, actually at the time).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Mar 31 19:43:29 2004