Database Revision Tracking
As part of a process improvement effort we're doing at LibLime, I've created the following wiki proposal: http://wiki.koha.org/doku.php?id=en:development:dbrevs:start Please read it and let me know what you think. This is intended as a simple replacement for IRC conversations like this: < random_dev> I'm pushing a patch with database version 105. Anybody else using that?
Jesse Weaver a écrit :
As part of a process improvement effort we're doing at LibLime, I've created the following wiki proposal:
http://wiki.koha.org/doku.php?id=en:development:dbrevs:start
Please read it and let me know what you think. This is intended as a simple replacement for IRC conversations like this:
definetly +++ for me ! And, pls, get the number *before* writing the stuff & commiting. It happends once (only once, fortunatly), that I claimed a number in my code, and the number has been taken by someone else. Was boring to fix it. So, let's go with this page. Thx for the idea ! -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc NOUVEAU TELEPHONE : 04 91 81 35 08
On 2008/08/1, at 7:00 PM, Paul POULAIN wrote:
Jesse Weaver a écrit :
As part of a process improvement effort we're doing at LibLime, I've created the following wiki proposal:
http://wiki.koha.org/doku.php?id=en:development:dbrevs:start
Please read it and let me know what you think. This is intended as a simple replacement for IRC conversations like this:
definetly +++ for me ! And, pls, get the number *before* writing the stuff & commiting. It happends once (only once, fortunatly), that I claimed a number in my code, and the number has been taken by someone else. Was boring to fix it. So, let's go with this page. Thx for the idea !
great idea Paul+++ ive been thinking about this for ages too...
On 2008/08/1, at 8:41 PM, Mason James wrote:
On 2008/08/1, at 7:00 PM, Paul POULAIN wrote:
Jesse Weaver a écrit :
As part of a process improvement effort we're doing at LibLime, I've created the following wiki proposal:
http://wiki.koha.org/doku.php?id=en:development:dbrevs:start
great idea Paul+++
ive been thinking about this for ages too...
oops, sorry Jesse - the great idea was yours
On Fri, Aug 1, 2008 at 3:00 AM, Paul POULAIN <paul.poulain@free.fr> wrote:
Jesse Weaver a écrit :
As part of a process improvement effort we're doing at LibLime, I've created the following wiki proposal:
http://wiki.koha.org/doku.php?id=en:development:dbrevs:start
Please read it and let me know what you think. This is intended as a simple replacement for IRC conversations like this:
definetly +++ for me ! And, pls, get the number *before* writing the stuff & commiting. It happends once (only once, fortunatly), that I claimed a number in my code, and the number has been taken by someone else. Was boring to fix it.
FWIW here is the approach I use which may help avoid that issue: 1. Make changes to local db and code. 2. Debug. 3. Make changes to kohastructure.sql, updatedatabase.pl, & kohaversion.pl 4. Commit and create patch. 5. git reset --hard HEAD~1. 6. git am -3 dbchanging.patch 7. Test to see if update goes ok (will note some errors when updatedatabase.pl attempts to INSERT/UPDATE/DROP/DELETE things that are already there/missing) 8. If my db version number is taken by that point, I simply: a. git reset --hard HEAD~1 b. change db ver number in dbchanging.patch c. do any git fetch/git rebase that needs to be to catch the new db rev number d. git am -3 dbchanging.patch 9. I have only run upon one or two occasions where this did no play nice and I had to hack at things to get them fixed. YMMV (Your Mileage May Vary) (Critique welcomed.) 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. HTH Chris -- Chris Nighswonger LibLime www.liblime.com chris.nighswonger@liblime.com
Hi, On Fri, Aug 1, 2008 at 7:00 AM, Chris Nighswonger <chris.nighswonger@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@liblime.com p: 1-888-564-2457 x709 skype: gmcharlt
"Jesse Weaver" <jesse.weaver@liblime.com> wrote:
As part of a process improvement effort we're doing at LibLime, I've created the following wiki proposal:
http://wiki.koha.org/doku.php?id=en:development:dbrevs:start
Please read it and let me know what you think. [...]
1. the wiki has no Edit link; 2. what happens if the patch creating (dbrev+1) is submitted before the patch creating (dbrev)? Blocking on the RM? I wonder whether some automated monitor for patches@koha.org for dbrev changes is a fairer way, or if there's some fatal problem with that? Regards, -- MJ Ray (slef) Webmaster for hire, statistician and online shop builder for a small worker cooperative http://www.ttllp.co.uk/ http://mjr.towers.org.uk/ (Notice http://mjr.towers.org.uk/email.html) tel:+44-844-4437-237
participants (6)
-
Chris Nighswonger -
Galen Charlton -
Jesse Weaver -
Mason James -
MJ Ray -
Paul POULAIN