EPrints Technical Mailing List Archive

Message: #00899

< Previous (by date) | Next (by date) > | < Previous (in thread) | Next (in thread) > | Messages - Most Recent First | Threads - Most Recent First

[EP-tech] Re: Change management

Hi Tim,

Thanks for the quick reply.
It's a relief to hear that only a few configuration items are stored in the database - please keep it that way!
IIRC, db attributes for custom fields also need to be created manually, so there is need for some synchronization mechanism dev->production. Anything else that comes to mind? 

Regards,
Jan Ploski

Tim Brody wrote:

On Thu, 2012-07-26 at 16:04 +0200, Jan Ploski wrote:

Hi,

Is there a comprehensive list of which EPrints configuration details are
stored in the file system and which in the database? Are all
configuration settings stored in the database exportable/importable
to/from the file system?

Background: although little tweaks via GUI may seem appealing for small
installations, in general they sound like asking for trouble. Ideally,
I'd like to have all configuration changes pass through version control
and also through a staging (test) system. This is required for
documentation and also for signing off changes by the client before they
are brought into production. Is anyone else using EPrints in this
manner? Are there recommended administration practices (except for
"backup before changes" - restoring backups may be quite problematic if
the data moves forward after changes)? Or is everyone just crossing
their fingers and tweaking their production EPrints directly?


Hi,

There are no configuration settings stored in the database, except for:

  - the subjects tree
  - individual user settings

The sensible approach is to store all of your configuration in a
revision control system (svn or similar). That is, everything below
archives/[archiveid]/cfg/. This can be periodically committed to reflect
any changes made via the GUI.

Larger sites will tend to have a development instance and a live
instance, with these reflected in different branches of your RCS.

And of course, you will want to have a backup strategy for the system as
a whole (the contents + database).




*** Options: http://mailman.ecs.soton.ac.uk/mailman/listinfo/eprints-tech
*** Archive: http://www.eprints.org/tech.php/
*** EPrints community wiki: http://wiki.eprints.org/