Jeg er ikke sikker på, om den originale plakat stadig overvåger dette, men jeg stiller spørgsmålet alligevel.
Det oprindelige indlæg anmodede om at kunne:
For automatisk at "låse" den nuværende procedure, du arbejder med, kan ingen andre i teamet foretage ændringer i den, før du er færdig.
Måske er problemet her et udviklingsparadigme mere end et produkts manglende evne til at "låse" den lagrede proc. Hver gang jeg hører "Jeg vil låse dette, så ingen andre ændrer det", får jeg med det samme følelsen af, at folk deler et skema, og at alle udvikler sig i det samme rum.
Hvis dette er tilfældet, hvorfor så ikke bare lade alle have deres eget skema med en kopi af datamodellen? Jeg mener seriøst folkens, det "koster" ikke noget at lave et andet skema. På den måde kan hver udvikler foretage ændringer, indtil de er blå i ansigtet uden at påvirke andre.
Et andet trick, jeg har brugt tidligere (på små teams), hvor det ikke var muligt at lade enhver udvikler have deres egen kopi af dataene på grund af størrelsen, var at have et masterskema med alle tabellerne og koden i, med offentlige synonymer, der peger på det hele. Så, hvis udvikleren ønsker at arbejde på en lagret proc, opretter han den blot i sin skema. På den måde finder Oracle-navneopløsningen, at en først i stedet for kopien i masterskemaet, hvilket giver dem mulighed for at teste deres kode uden at påvirke nogen andre. Dette har sine ulemper, men dette var et meget specifikt tilfælde, hvor vi kunne leve med dem. Jeg ville selvfølgelig ALDRIG implementere sådan noget i produktionen.
Hvad angår det andet krav:
For automatisk at sende de ændringer, du foretager i den lagrede procedure, i en Oracle-database, til et Subversion, CVS,... repository
Jeg ville blive overrasket over at finde værktøjer derude, der er smarte nok til at gøre dette (måske en mulighed :). Den skulle oprette forbindelse til din db, forespørge i dataordbogen (USER_SOURCE) og trække den tilhørende tekst ud. En stor ordre for kildekontrolsystemer, hvor de er næsten universelt filbaserede.