Subversion (svn + tortoiseSvn) commit no file bloqueado

He experimentado una extraña funcionalidad de subversión.

Estamos utilizando el último server svn 1.6 svn visual svn y tortuga svn 1.6.6

Hemos definido la propiedad svn: needs-lock en un file, luego, si copymos el file desde una location diferente, se muestra un cambio local si intentas asignar SVN, lo que te permite confirmar incluso si no obtuviste el BLOQUEO.

Este es un gran problema para nosotros, por favor, háganos saber cómo forzar a SVN a no permitir confirmaciones sin get el locking.

Gracias.

El mecanismo de locking en Subversion no le dará, de inmediato, una forma de evitar confirmaciones sin un locking primero.

Es posible, énfasis en el poder , ser capaz de manejar eso con los ganchos del server, pero no estoy seguro. Quizás deba hacer una nueva pregunta en la que pregunte cómo crear un script de subversión del server de subversión que evite que las personas realicen cambios si primero no poseen el locking del file.

El mecanismo de locking es solo una herramienta adicional para administrar files problemáticos, como files de diseñador donde el contenido se mueve mucho (por lo tanto, la fusión es un problema), o para files binarys, si los almacena. Pero el mecanismo de locking no está listo para evitar que se comprometa sin un candado, sino que es una conveniencia, pero puede evitarse fácilmente.

Subversion proporciona la funcionalidad de locking como una conveniencia para ayudar a los usuarios a administrar cambios concurrentes a files que de otro modo no se pueden combinar. Siempre es posible "robar" un locking en Subversion, por lo que la comunicación entre committers puede ser necesaria. Puede get el mismo efecto que describe desactivando el atributo de solo lectura en un file.

Si necesita protegerse contra los usuarios que usan indebidamente la function de locking, quizás Subversion no sea la herramienta adecuada para usted. Otros productos como Perforce o ClearCase son mucho más estrictos con los protocolos de locking.

La propiedad es svn:needs-lock no svn-needs-lock . Ese podría ser tu problema.

Además, la subversión no le permite forzar lockings en nadie. Los lockings pueden anularse utilizando la opción `–force“.

Configurar la propiedad svn: needs-lock no tiene nada de especial: le dice a Subversion que configure el indicador de 'solo lectura' en esos files cuando realice el check-out o la actualización.

De modo que, idealmente, todos los files con el set de properties svn: needs-lock tienen establecido el indicador readonly. Cuando obtiene el locking de svn, Subversion elimina el indicador de solo lectura para que pueda editar el file.

Entonces, lo que está sucediendo en su situación es esto: está reemplazando un file que tiene el indicador de solo lectura configurado con otro file que no tiene este indicador establecido. Y Windows no usa el indicador de solo lectura del file reemplazado.