[Koha-devel] Database Revision Tracking

[Galen Charlton]

Hi,

On Fri, Aug 1, 2008 at 7:00 AM, Chris Nighswonger
<chris.nighswonger at liblime.com> wrote:
> Some procedure like this would allow db ver numbers to be claimed as
> the patch is submitted, avoiding (hopefully) regularly occurring db
> ver number clashes.

I think this is the key point - the DB revision number itself should
be claimed just before the patch is submitted.  There will still be
the potential for clashes, though:

1. DB rev patches n and n+1 get submitted.
2. QA or RM finds a problem with rev n that will take a couple days to fix.
3. If n+1 is not to be blocked, then the revs will need to be reordered.

This sort of problem can be reduced, although not eliminated by
submitting significant DB rev patches for community review before
claiming a number.

However, a longer-term fix (maybe for 3.2) would be to change
updatedatabase.pl so that it doesn't require a strictly linear order
of DB changes.  Instead, each Koha database could keep a table of DB
changes that have been applied to it, and during a version update,
updatedatabase.pl could check that registry and apply any missing DB
revs.  Under that scenario, if patches n and n+1 don't depend on each
other, then it would be easier for the RM to apply n+1 to git first,
then n a couple days later.  Ideally we'd structure things in such a
way that git merge conflicts are minimized, possibly by putting the
SQL for each DB rev in a separate file.

Regards,

Galen
-- 
Galen Charlton
VP, Research & Development, LibLime
galen.charlton at liblime.com
p: 1-888-564-2457 x709
skype: gmcharlt