¿Por qué no puedo editar un mensaje de confirmación SVN?

Estoy usando SVN. A veces extraño algo cuando escribo un mensaje de confirmación. Pero una vez que se ha comprometido, no se puede revertir, e incluso yo no puedo editar el mensaje. ¿Por qué no pusieron la función de edición?

version-control svn

— Sanghyun Lee
fuente

Me recuerda la historia de Dave.cpp en thedailtywtf

— Falcon el

Simplemente use git , permite fusionar confirmaciones, editar mensajes y hacer lo que quiera con su historial.

— SK-logic

O si no puede, entonces use git-svny nadie será más sabio.

— Matthew Scharley

@Matthew: ¿cómo diablos con git-svn le permite cambiar el historial en un repositorio svn con edición de historial desactivado?

— gbjbaanb

@gbjbaanb: No lo haría, si ya has subido al servidor SVN. Pero si solo se ha comprometido localmente, aún puede cambiar el mensaje de confirmación antes de incluirlo en el repositorio en vivo.

— Matthew Scharley

Respuestas:

Según las preguntas frecuentes de SVN, puede hacerlo si el administrador del repositorio lo ha habilitado o si tiene acceso administrativo local al repositorio .

Sin embargo, hacer esto es probablemente una mala idea. Estás, en efecto, cambiando la historia. Uno de los puntos del control de versiones es mantener un historial y una pista de auditoría para el proyecto. Permitir cambios arbitrarios en el historial derrota la pista de auditoría. En cambio, recomendaría que realice confirmaciones más pequeñas, escriba mensajes de confirmación concisos pero explícitos y mejore su flujo de trabajo personal para evitar estos errores.

— Thomas Owens
fuente

@Matthew Incluso en git, cambiar la historia en cualquier momento es, en mi opinión, una idea terrible. Se supone que el historial sirve como una pista de auditoría y que nadie debe cambiarlo en ningún momento por ningún motivo.

— Thomas Owens

Por lo tanto, tenga una pista de auditoría para el mensaje de confirmación, porque generalmente el propósito de cambiar el mensaje de confirmación es facilitar el seguimiento del historial del proyecto.

— Peter Taylor

Supongamos que descubro que un mensaje de confirmación que ingresé hace un mes es engañoso, confuso y francamente incorrecto . ¿No debería poder agregar una notación de corrección que será vista por todos los que vean el mensaje incorrecto? (Estoy de acuerdo en que el mensaje original debe estar fácilmente disponible sin modificaciones y el cambio en sí mismo debe ser rastreado y marcado. Pero no estoy de acuerdo con que esto constituya una "historia cambiante".)

— David Schwartz

La información incorrecta es inaceptable, por lo tanto, no se debe permitir que las personas corrijan o aclaren esa información, ya que eso ocultaría su malversación. Guau. Simplemente guau.

— David Schwartz

Sinceramente, comienzas a parecer una auto parodia. "Tiene que ser correcto, por lo tanto, nunca debe corregirse".

— David Schwartz

Esencialmente, debe tener derechos de administrador (directa o indirectamente) sobre el repositorio para hacer esto. Puede configurar el repositorio para permitir que todos los usuarios hagan esto, o puede modificar el mensaje de registro directamente en el servidor.

Consulte las preguntas frecuentes de SVN aquí.
Los mensajes de registro se guardan en el repositorio como propiedades adjuntas a cada revisión. De manera predeterminada, la propiedad del mensaje de registro (svn: log) no se puede editar una vez que se confirma. Esto se debe a que los cambios en las propiedades de revisión (de los cuales svn: log es uno) hacen que el valor anterior de la propiedad se descarte permanentemente, y Subversion intenta evitar que lo haga accidentalmente. Sin embargo, hay un par de formas de hacer que Subversion cambie una propiedad de revisión.

La primera forma es que el administrador del repositorio habilite las modificaciones de propiedad de revisión. Esto se hace creando un gancho llamado "pre-revprop-change" (vea esta sección en el libro de Subversion para más detalles sobre cómo hacer esto). El enlace "pre-revprop-change" tiene acceso al antiguo mensaje de registro antes de que se cambie, por lo que puede preservarlo de alguna manera (por ejemplo, enviando un correo electrónico). Una vez que se habilitan las modificaciones de propiedades de revisión, puede cambiar el mensaje de registro de una revisión pasando el modificador --revprop a svn propedit o svn propset, como cualquiera de estos:
$svn propedit -r N --revprop svn:log URL 
$svn propset -r N --revprop svn:log "new log message" URL 
donde N es el número de revisión cuyo mensaje de registro desea cambiar y URL es la ubicación del repositorio. Si ejecuta este comando desde una copia de trabajo, puede omitir la URL.

La segunda forma de cambiar un mensaje de registro es usar svnadmin setlog. Esto debe hacerse haciendo referencia a la ubicación del repositorio en el sistema de archivos. No puede modificar un repositorio remoto con este comando.
$ svnadmin setlog REPOS_PATH -r N FILE
donde REPOS_PATH es la ubicación del repositorio, N es el número de revisión cuyo mensaje de registro desea cambiar y FILE es un archivo que contiene el nuevo mensaje de registro. Si el enlace "pre-revprop-change" no está en su lugar (o si desea omitir el script de enlace por algún motivo), también puede usar la opción --bypass-hooks. Sin embargo, si decide usar esta opción, tenga mucho cuidado. Puede omitir cosas como notificaciones por correo electrónico del cambio o sistemas de respaldo que realizan un seguimiento de las propiedades de revisión.

Respuesta de Kamil Kisiel en respuesta a una pregunta similar sobre Stack Overflow .

— Abimaran Kugathasan
fuente

Cuando copie y pegue una respuesta de stackoverflow, al menos debe marcarla como una cita y dar crédito al OP (Kamil Kisiel en este caso). Enlace al original: stackoverflow.com/questions/304383/… Por favor, edite su respuesta o voy a denunciarlo.

— Falcon

Debido a que es un sistema de control de versiones centralizado : tan pronto como confirma un cambio (y su mensaje de confirmación está vinculado por convención a la confirmación), todos los que tienen acceso de lectura al repositorio pueden ver esa información. Es una mala idea cambiar la información después de que se haya difundido , porque las personas terminan con una opinión diferente de la "realidad".

Los sistemas de control de versiones distribuidos como Git alivian este problema asegurándose de que el acto de hacer que la información esté disponible para otros es atómica y sin ninguna información adicional como mensajes de confirmación. Pero el mismo principio se aplica aquí: se le desaconseja cambiar las cosas localmente que ya ha puesto a disposición de otros.

— l0b0
fuente

Podrían permitir múltiples versiones del mensaje de confirmación ...

— Alex Feinman

@ l0b0 ¿no es objetivamente peor continuar difundiendo información falsa, engañosa o propensa a causar daños? El mantenimiento de registros no requiere que se conserven datos incorrectos.

— user179700

@ user179700: Tienes razón. Hay una suposición de diseño fundamentalmente defectuosa en todos los VCS que he visto: una confirmación tiene un mensaje de confirmación, que es inmutable. Como dice Alex, deberíamos "permitir múltiples versiones del mensaje de confirmación".

— l0b0

@ l0b0 Me parece interesante esta pregunta cuanto más la considero. Mi primera reacción fue similar a la de simplemente escribir con más cuidado. La práctica actual parece dificultar el proceso. También me pregunto si algún otro sistema implementa una práctica más sólida. Es hora de otra pregunta, me parece. +1

— user179700

@ user179700: actualmente espero escribir un script que le permita cambiar un mensaje de confirmación, pero solo agregando una cadena adicional (con marca de tiempo). Eso le permite corregir errores mientras preserva la pista de auditoría.

— Tynam