If you cannot get logged in, clear your cookies for and retry. The Foswiki Cookie Domain has been changed.
You are here: Foswiki>Tasks Web>Item13068 (25 Jan 2015, GeorgeClark)Edit Attach

Item13068: PlainFileStore / Foswiki bootstrap and migration considerations

Priority: Urgent
Current State: Closed
Released In: 1.2.0
Target Release: minor
Applies To: Engine
Component: CompareRevisionsAddOn, FoswikiConfigureLoad, PlainFileStoreContrib, ConfigureBootstrap
Branches: master
Reported By: GeorgeClark
Waiting For:
Last Change By: GeorgeClark
We need some "help" for users migrating to 1.2. Existing sites would be using an RCS based store, but the default configuration with 1.2 is to use the PlainFileStoreContrib.

  • Bootstrap should probably detect presence of rcs,v files, and set an RCS based store instead of Plain File
    • Probably best to just set RcsLite, since it's most portable
    • Not very reliable if sites migrate using a fresh install.
  • CompareRevisionsAddOn ships an rcs,v file. We need to consider how best to handle this. Maybe just not ship it and remove the example. The package installer can't handle it either.
  • Configure checker should look for rcs,v files an warn that migration is required if PlainFileStore is selected.

We also need some very clear / visible migration instructions.

-- GeorgeClark - 02 Nov 2014

Crawford, after reading your HowToWriteASpecFile, I'm wondering if a checker is the right solution. I expect a "quick" search to find find if any "...,v" files exist in data (or pub?) subdirectories will be too slow. But since we are changing the default for the type of store, I think we really need something like this. Another thought was we could set a flag that the check has been done, so we don't check over and over, but this probably isn't right either. That means the checker would be modifying the config or touching a "check_completed" file.

What if we were to make the "Choose your Store implementation" a Wizard, and make the actual Store setting an Expert setting. I don't think we need to go as far as make the migration tool part of a wizard. That would probably run way too long on large webs. I don't think we need to go further than ensuring that changes to Store implementation are "safe".

Looking at my own test system, where I bounce back and forth between 1.1.x, and 1.2.x, my file system is really a mess. I didn't notice that the default for Store was changing and all of my webs are a mixed bag of *.pfv directories and txt,v rcs files.

Working through what might be a "typical" upgrade / migration: (I've used approach this many times)
  • Site sets up a test server, installs Foswiki 1.2
  • Initial bootstrap, default PlainFile store is selected
  • Basic testing works (creating .pfv directories)
  • Admin copies over contents of Main, and other data webs
    • ALERT! Wrong store method is set for copied content.

Another thought might be to add checking in Store, and throw an error if either a .pfv directory exists when saving from an Rcs* store, or a ",v" file exists when saving in the PlainFile store.

-- GeorgeClark - 03 Nov 2014

I think a checker should detect when ,v files are present, and raise an error if PlainFileStore is selected (and the converse for RCS when .pfv are detected). If you want to transition, then it should be done as a clear, distinct step. It's too complex to support it piecemeal.

ERROR: PlainFileStore is selected but you have ,v files present on in the directory tree, suggesting that your filestore is actually using RCS. Before using PlainFileStore you should migrate the store using some script or other that's lying around in tools, I think. Sorry, I've forgotten.

and the equivalent for RCS.

These checkers should be part of the PlainFileStoreContrib and RCSStoreContrib - it's not the core's job to disentangle store implementations.

If you use configure the checker will not be run unless the Store tab is opened. I do not favour it being an expert setting, however.

-- CrawfordCurrie - 05 Nov 2014
Topic revision: r10 - 25 Jan 2015, GeorgeClark - This page was cached on 24 Jan 2017 - 12:19.

The copyright of the content on this website is held by the contributing authors, except where stated elsewhere. See Copyright Statement. Creative Commons License