Je ne sais pas si l'affiche originale surveille toujours cela, mais je poserai quand même la question.
Le message d'origine demandait à pouvoir :
Pour "verrouiller" automatiquement la procédure actuelle avec laquelle vous travaillez, personne d'autre dans l'équipe ne peut y apporter de modifications jusqu'à ce que vous ayez terminé.
Peut-être que le problème ici est un paradigme de développement plus que l'incapacité d'un produit à "verrouiller" le proc stocké. Chaque fois que j'entends "Je veux verrouiller ceci pour que personne d'autre ne le modifie", j'ai immédiatement l'impression que les gens partagent un schéma et que tout le monde se développe dans le même espace.
Si tel est le cas, pourquoi ne pas simplement laisser chacun avoir son propre schéma avec une copie du modèle de données ? Je veux dire sérieusement les gens, cela ne "coûte" rien de créer un autre schéma. De cette façon, chaque développeur peut apporter des modifications jusqu'à ce qu'ils soient bleus au visage sans affecter personne d'autre.
Une autre astuce que j'ai utilisée dans le passé (sur de petites équipes) lorsqu'il n'était pas possible de laisser chaque développeur avoir sa propre copie des données en raison de la taille, était d'avoir un schéma maître avec toutes les tables et le code qu'il contient, avec des synonymes publics pointant vers tout cela. Ensuite, si le développeur veut travailler sur une proc stockée, il la crée simplement dans son schéma. De cette façon, la résolution de noms Oracle trouve celui-ci en premier au lieu de la copie dans le schéma maître, ce qui leur permet de tester leur code sans affecter personne d'autre. Cela a ses inconvénients, mais c'était un cas très spécifique où nous pouvions vivre avec eux. Je n'implémenterais JAMAIS quelque chose comme ça en production évidemment.
Quant à la deuxième exigence :
Pour envoyer automatiquement les modifications que vous effectuez dans la procédure stockée, dans une base de données Oracle, vers un référentiel Subversion, CVS,...
Je serais surpris de trouver des outils suffisamment intelligents pour le faire (peut-être une opportunité :). Il devrait se connecter à votre base de données, interroger le dictionnaire de données (USER_SOURCE) et extraire le texte associé. Un défi de taille pour les systèmes de contrôle de code source qui sont presque universellement basés sur des fichiers.
