Hi, On Fri, Aug 1, 2008 at 7:00 AM, Chris Nighswonger <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] p: 1-888-564-2457 x709 skype: gmcharlt _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
