Jag är inte säker på om den ursprungliga affischen fortfarande övervakar detta, men jag ställer frågan ändå.
Det ursprungliga inlägget begärde att kunna:
För att automatiskt "låsa" den nuvarande proceduren du arbetar med kan ingen annan i teamet göra ändringar i den förrän du är klar.
Kanske är problemet här ett utvecklingsparadigm mer än oförmågan hos en produkt att "låsa" den lagrade proc. När jag hör "Jag vill låsa det här så att ingen annan ändrar det" får jag direkt en känsla av att människor delar ett schema och att alla utvecklas i samma utrymme.
Om så är fallet, varför inte helt enkelt låta alla ha sitt eget schema med en kopia av datamodellen? Jag menar seriöst gott folk, det "kostar" ingenting att skapa ett annat schema. På så sätt kan varje utvecklare göra ändringar tills de är blå i ansiktet utan att påverka någon annan.
Ett annat knep jag har använt tidigare (på små team) när det inte var möjligt att låta varje utvecklare ha sin egen kopia av data på grund av storleken, var att ha ett huvudschema med alla tabeller och kod i det, med offentliga synonymer som pekar på det hela. Sedan, om utvecklaren vill arbeta med en lagrad proc, skapar han den helt enkelt i sin schema. På så sätt hittar Oracle-namnupplösningen det först istället för kopian i huvudschemat, vilket gör att de kan testa sin kod utan att påverka någon annan. Detta har sina nackdelar, men det här var ett mycket specifikt fall där vi kunde leva med dem. Jag skulle ALDRIG implementera något liknande i produktionen så klart.
När det gäller det andra kravet:
För att automatiskt skicka ändringarna du gör i den lagrade proceduren, i en Oracle-databas, till ett Subversion-, CVS-,...-förråd
Jag skulle bli förvånad över att hitta verktyg där ute som är tillräckligt smarta för att göra detta (kanske en möjlighet :). Den skulle behöva ansluta till din db, fråga dataordboken (USER_SOURCE) och dra ut den associerade texten. En stor order för källkontrollsystem där är nästan universellt filbaserade.