2009-06-16 8 views
5

Utilizamos svn: externals para revisiones específicas de una biblioteca, p. Ej. comoCómo prohibir los commits de subversión a svn: externos a las revisiones?

xyzlib -r12345 https://asdf.asdf.local/xyzlib/trunk/ 

Al realizar una modificación en su copia de trabajo a tal desprotegido externo, es posible confirmar, incluso aunque los enlaces externos a una revisión específica y no la cabeza.

Cuando ejecuta svn update después de la confirmación, los cambios se eliminarán en la copia de trabajo porque la subversión revierte todo a la revisión 12345. Por lo tanto, nunca verá realmente los cambios pero todavía están en HEAD, lo cual es malo .

¿Es posible prohibir confirmaciones solo cuando el externo no apunta a la revisión HEAD?

+0

¿Qué significa "comprometerse con estas cosas externas" significa? ¿Alguien comprometido con https: //asdf.asdf.local/xyzlib/trunk/? ¿LA CABEZA de qué contiene qué modificación? –

+0

Ive reformuló la pregunta un poco – martinus

Respuesta

3

Para este tipo de validaciones también recomendaría un gancho precompromiso, pero en lugar de escribir un script que puede resultar imposible de entender, recomiendo usar una biblioteca como SVNKit - http://svnkit.com/ (si conoce Java) .

He escrito unos ganchos de precompromiso con esta biblioteca y es bastante fácil trabajar con ella. Usted escribe un pequeño programa ejecutable de Java que es llamado desde el enlace precompromiso por Subversion. Entonces es fácil de extraer, p. propiedades o partes de la URL para hacer la validación y rechazar la confirmación si no se aplica a sus "reglas".

Echa un vistazo a las clases SVNLookClient y SVNChangeEntry - tienen métodos para los casos más comunes (. Por ejemplo, la extracción de información sobre una confirmación en curso)

1

Dado que está utilizando https, supongo que está utilizando mod_dav_svn. Puede configurar una url adicional en el repositorio de su biblioteca y solo otorgarle acceso de solo lectura. De esta forma, incluso los desarrolladores que normalmente pueden comprometerse con la biblioteca no podrán comprometerse a través de svn: external.

+0

hm Realmente no me gusta esto porque cuando me cambio a la CABETA de la URL escribible todos los archivos tienen que eliminarse y volverse a comprobar – martinus

+1

¿Entonces está cambiando el svn: external a una revisión diferente? Nunca he intentado cambiar uno antes, pero no veo por qué debería forzar una eliminación en la copia de trabajo. –

+2

El problema, supongo, es que no cambiará, seguirá siendo r12345 después de la próxima actualización. Y los cambios comprometidos entrarán en HEAD (o fallarán con el conflicto). Eso no es lo que el desarrollador de commit estaba pensando de ninguna manera. – Eugene

2

Puede intentar algo como esto: use un pre-commit script para verificar si la confirmación va a una etiqueta. Si es así, fallar y proporcionar un mensaje. Read some more about subversion hooks. Tendrá que volver a escribir la expresión regular para que falle si no es HEAD en lugar de fallar si es una etiqueta.

$SVNLOOK changed -t “$TXN” “$REPOS” | egrep -v “^[AD][[:space:]]+(.*/)?tags/[^/]+/$” | egrep “^[^[:space:]]+[[:space:]]+tags/[^/]+/.+” 
if [ $? -eq 0 ] ; then 
echo >&2 “***************************************” 
echo >&2 “* Modification of tags is not allowed *” 
echo >&2 “***************************************” 
exit 1 
fi 
1

Si no se ha comprometido a mantener el entorno externo definido como una revisión del enlace troncal, ¿por qué no crear una nueva etiqueta basada en esa revisión? Luego puede tener su svn: punto externo a la etiqueta, y usar uno de los métodos de control de acceso documentados para limitar las confirmaciones a su directorio de etiquetas (o poner la etiqueta en un repositorio diferente y hacer que ese repositorio solo sea de lectura).

Cuestiones relacionadas