[SVN] SQL commando`s bewaren, uitvoeren

[decramy]

Ik wil dmv hook scripts 'versiebeheer' op m`n database toepassen. Het hoeft niet backwards compatible te zijn.

Zelf had ik zoiets in gedachte:
developer maakt in mapje SQL een file new.sql aan, met daarin z`n SQL commando`s. ALTER TABLE en dergelijke.
developer commit. new.sql wordt hernoemt naar `$rev +1`.sql, geadd aan de repos en dan gebeurd de echte commit.

Bash:

#!/bin/sh
co=`find ~ -type f |egrep projectX/.svn/entries$|awk '{print substr($1, 0, length($1)-12)}'`
rev=`svnlook youngest $1`
newrev=`expr $rev + 1`

if [ -e $rep/SQL/new.txt ] ; then
  mv $co/SQL/new.txt $co/SQL/$newrev.txt
  svn add $co/SQL/$newrev.txt
fi

Maar bij deze setup in start-commit, is de repos al gelocked...

Heb ik nu een hele foute gedachtegang, of... hoe los ik die locks goed op?

[Verwijderd]

En wat als je de pre-commit hook gebruikt?

[decramy]

dan is de boel ook al gelocked

[Verwijderd]

Bedoel je hier:

developer commit. new.sql wordt hernoemt naar `$rev +1`.sql, geadd aan de repos en dan gebeurd de echte commit.

Dat je new.sql wilt verplaatsen of copieren naar `$rev +1`.sql, met de complete versie history erbij?

Ik denk dat je het via een andere weg moet proberen, zonder aan die txt files te komen.

Wat als je in de post-commit hook dit doet?

code:

svn move new.sql `$rev +1`.sql

Of is het dan nog steeds gelocked?

[LuCarD]

While hook scripts can be leveraged to do almost anything, there is one dimension in which hook script authors should show restraint: do not modify a commit transaction using hook scripts. While it might be tempting to use hook scripts to automatically correct errors or shortcomings or policy violations present in the files being committed, doing so can cause problems. Subversion keeps client-side caches of certain bits of repository data, and if you change a commit transaction in this way, those caches become indetectably stale. This inconsistency can lead to surprising and unexpected behavior. Instead of modifying the transaction, you should simply validate the transaction in the pre-commit hook and reject the commit if it does not meet the desired requirements. As an added bonus, your users will learn the value of careful, compliance-minded work habits

http://svnbook.red-bean.c...n.reposadmin.create.hooks

Weet je wel zeker dat je dit wilt?

[Verwijderd]

En uit hetzelfde gequote boek van LuCarD blijkt dat je ook de pre-lock en de post-unlock hook kunt gebruiken:

code:

$ ls repos/hooks/
post-commit.tmpl      post-unlock.tmpl  pre-revprop-change.tmpl
post-lock.tmpl        pre-commit.tmpl   pre-unlock.tmpl
post-revprop-change.tmpl  pre-lock.tmpl     start-commit.tmpl

Maar ik moet toegeven dat ik hier nog met CVS werk, dus je zult waarschijnlijk zelf je conclusies moeten trekken over wat je precies wilt.

[djc]

Hmmm, je zou ook in een revprop van de commit kunnen opslaan welk bestandje er bij die commit hoort. Revprops kan je gewoon na de commit aanbrengen (bijvoorbeeld in de post-commit hook), omdat ze niet versioned zijn. Op die manier krijgen je bestandjes geen naam die identiek is aan de revisie waarin ze gebruikt worden, maar je kan ze wel gewoon opvolgende nummers geven ofzo.

Enige nadeel is misschien dat je niet echt heel makkelijk kan opzoeken gegeven een bestandsnaam welke revisie erbij hoort (omdat zoeken door props niet echt SVN's sterkste punt is).

[decramy]

@manuzhai
tevens kan ik dan niet een checkout scp`n naar de live server...

@algemeen
Hoe hou ik dan wijzigingen in SQL bij? Is er een manier voor?

[decramy]

*schop?