No estoy seguro de si el póster original sigue controlando esto, pero de todos modos haré la pregunta.
El post original solicitada para ser capaz de:
Para automáticamente "bloquear" el procedimiento actual que está trabajando, por lo nadie más en el equipo puede hacer cambios en él hasta que esté terminada .
Quizás el problema aquí sea uno de los paradigmas de desarrollo más que la incapacidad de un producto para "bloquear" el proceso almacenado. Cada vez que escucho "Quiero bloquear esto para que nadie más lo cambie", inmediatamente tengo la sensación de que las personas comparten un esquema y que todos se están desarrollando en el mismo espacio.
Si este es el caso, ¿por qué no simplemente dejar que cada uno tenga su propio esquema con una copia del modelo de datos? En serio, amigos, no "cuesta" nada crear otro esquema. De esta forma, cada desarrollador puede hacer cambios hasta que estén azules en la cara sin afectar a nadie más.
Otro truco que he usado en el pasado (en equipos pequeños) cuando no era factible permitir a cada desarrollador tener su propia copia de los datos debido al tamaño, era tener un esquema maestro con todas las tablas y código en él, con sinónimos públicos apuntando a todo. Entonces, si el desarrollador desea trabajar en un proceso almacenado, simplemente lo crea en su esquema. De esta forma, la resolución de nombres de Oracle encuentra esa primera en lugar de la copia en el esquema maestro, lo que les permite probar su código sin afectar a nadie más. Esto tiene sus inconvenientes, pero este fue un caso muy específico en el que pudimos vivir con ellos. NUNCA NUNCA implementaría algo como esto en producción obviamente.
En cuanto al segundo requisito:
Para enviar automáticamente los cambios que realice en el procedimiento almacenado, en una base de datos Oracle, a un Subversion, CVS ... repositorio
Me sorprendería encontrar herramientas lo suficientemente inteligentes como para hacer esto (tal vez una oportunidad :). Tendría que conectarse a su base de datos, consultar el diccionario de datos (USER_SOURCE) y extraer el texto asociado. Una tarea difícil para los sistemas de control de origen en la que casi todos los archivos se basan.
Como veo, la herramienta de versiones de SQL Developer solo maneja los archivos y no brinda soporte para el segundo requisito anterior. ¿Me estoy perdiendo de algo? – rics