tag - tortoise svn server
¿Por qué el borrado no es una característica esencial de Subversion? (13)
Desde hace algunos años, estoy esperando a que Subversion muestre una función de "eliminar permanentemente" (eliminar). Dudo en hacer la transición a Subversion (proveniente de Visual SourceSafe: p), porque creo que esta es una característica esencial, ya que de lo contrario esperaría que el repositorio crezca de manera imparable. Sin embargo, por una razón u otra, la función se pospone una y otra vez. Así que empiezo a preguntarme si hay alguna otra característica o solución que haga prescindible la función de borrado.
¿Qué haces cuando quieres reducir el depósito central de SVN?
Ejemplo 1 : verifico una gran biblioteca de terceros , y después de unas semanas me doy cuenta de que no es adecuada para mis necesidades. No quiero que eso almacene y respalde esa gran cantidad de datos para siempre.
Ejemplo 2 : Tengo 10 versiones de 10 bibliotecas de terceros grandes en el repositorio, pero solo uso las últimas versiones.
Ejemplo 3 : accidentalmente verifiqué información confidencial (como lo sugirió John ).
Ejemplo 4 : accidentalmente comprobé algunos archivos grandes que nunca debieron colocarse en el repositorio.
Citando a Subversion Obliterate, la característica olvidada , hay tres componentes a la pregunta, el problema , la razón y la solución . Desde que empezaste con la pregunta para la solución, comenzaré con eso.
Solución
Como habrás notado, no hay una gran solución. Especialmente si está tratando con un gran repositorio corporativo, ya que la solución se vuelve más difícil cuanto más grande es el repositorio. Hay una función llamada volcado / filtro a través de la cual puede limpiar su repo de cosas que no desea, pero no es tan fácil de usar, no es rápido ni confiable.
Ha habido un pequeño esfuerzo (seguir el hilo) en el equipo de svn para obtener una función de borrado allí después de 2008, pero el esfuerzo murió como una muerte silenciosa.
El problema
El artículo que mencioné al principio en realidad tiene una buena lista de casos de uso en los que uno necesitaría un comando de eliminación y en el subproceso 516, los desarrolladores reconocieron su mérito.
Ay, parece demasiado tarde para eso ahora; la verdadera razón por la que nunca se agregó más tarde fue que ahora es casi imposible implementarlo, ya que se enlaza al código en el nivel más fundamental (también vea el enlace de esfuerzo pequeño en la Solución).
De la entrada de preguntas frecuentes :
Las revisiones son árboles inmutables que se construyen unos sobre otros. Eliminar una revisión de la historia causaría un efecto dominó, creando un caos en todas las revisiones posteriores y posiblemente invalidando todas las copias de trabajo.
La razón
El problema es que originalmente la función de eliminación de datos se descartó porque no cumplía con el principio de control de versión real.
Una vez más de la entrada de preguntas frecuentes :
¿Cómo elimino por completo un archivo del historial del repositorio? Hay casos especiales en los que es posible que desee destruir toda la evidencia de un archivo o confirmación. (Tal vez alguien accidentalmente cometió un documento confidencial). Esto no es tan fácil, porque Subversion está diseñado deliberadamente para no perder nunca información .
sin embargo
He trabajado con SVN para muchos clientes ahora con equipos más grandes y proyectos más grandes y, básicamente, nunca tuve un problema real. Sí, los casos de uso mencionados justifican una función de borrado, pero hasta ahora no estoy convencido de que este sea un problema que tenga una y otra vez donde quiera que vaya. Por supuesto, la naturaleza de este problema en particular es que solo tiene que cometer un error una vez y no se puede deshacer adecuadamente.
Debido a que la eliminación de datos del repositorio rompe la premisa básica del control de origen, es que es posible reproducir todos los estados anteriores y los cambios en el árbol de origen. Si desea eliminar algo del control de versiones, probablemente esté "Haciéndolo mal", como dicen.
Es posible reducir el tamaño de un repositorio SVN haciendo un volcado y carga. Esencialmente, si dice que nunca desea volver a algo más de un par de años, es posible volcar el repositorio, filtrar por tiempo y luego volver a cargar el volcado. Querer deshacerse de un solo archivo debido a su tamaño es probablemente una indicación de que el archivo no pertenecía realmente a un sistema de control de origen en primer lugar.
Existe una buena cantidad de discusión sobre svn obliterate en el ticket del problema en el sitio de Apache Subversion , la mayoría de los cuales termina en 2008. Parece haber un acuerdo general de que es una buena capacidad, aunque su uso debería ser poco frecuente.
Hay dos razones principales para quererlo.
Primero, el registro de información confidencial puede ser un problema. Dejarlo ahí, borrado, no es necesariamente una opción, dependiendo del nivel de confidencialidad y la exposición del repositorio.
En segundo lugar, registrar una gran cantidad de cosas que no deberían ser registradas puede aumentar drásticamente el tamaño del repositorio. El espacio en disco es generalmente barato en la actualidad, pero no es ilimitado, y hay otras maneras en que el espacio de archivos puede importar. Si es necesario enviar un repositorio a través de una conexión de red, es tiempo adicional que puede o no ser importante. Puede haber ventajas reales al poder grabar un CD-ROM o DVD-ROM que contiene todo el repositorio.
Por lo tanto, es una capacidad útil que se realiza actualmente al descargar, filtrar y volver a cargar el repositorio. Esto es propenso a errores según los informes que he visto, puede ser lento y requiere cerrar el repositorio.
Obviamente, no es una función de alta prioridad para el equipo de Subversion, dado que lo que se necesita durante varios años es que alguien haga el trabajo para diseñar y ponerlo en práctica. Después de todo, se debe hacer muy raramente, y hay una solución. Sin embargo, cualquier persona que quiera hacer un montón de trabajo en Subversion podría proporcionar un parche que probablemente se implementaría (si es de buena calidad).
Hay algunos scripts que te ayudan a borrar datos. Siga este hilo de la lista de correo para más información.
Es una manera difícil de hacerlo ya que la esencia del control de versiones es no perder datos, en lugar de eliminarlos permanentemente. Pero si podas una vez al año o algo así, se puede hacer.
La última vez que lo comprobé estaba pensada como una función ADMIN, y el administrador ya puede volcar / filter / broken_workaround y eliminar el historial de todos modos. En lo que respecta a la pista de auditoría, esto no cambia la cita actual. Lo haría menos horrible, si algo absolutamente debe ser eliminado.
El borrado de Svnadmin es una de las características más solicitadas, los desarrolladores finalmente admiten que debería existir (¡¡finalmente, después de 8 años!). Y la publicidad de que no existe, está alejando a los usuarios de SVN.
Desafortunadamente, tuve que aprender sobre esta "característica que falta" de la manera más difícil. ¿Desde cuándo es una funcionalidad básica una característica? Los nuevos usuarios están empezando a escuchar acerca de esto y evitan SVN. En cuanto a mí, ahora uso Git.
¿No me gusta mi opinión? Linus se refirió a los desarrolladores de SVN como idiotas, y todo el sistema centralizado fue defectuoso. Confío en Linus como un verdadero experto, y específicamente Él sabe acerca de la fuente.
La razón obvia en contra de esto es que los desarrolladores creen que, en general, empeorará el SVN: la ira que se siente al poder podar cosas innecesarias se verá muy afectada por su enojo cuando borre algo accidentalmente y su / tronco se pierda.
FogBugz tiene exactamente el mismo comportamiento, y creo que en su caso es totalmente de diseño, protegiendo a los usuarios de ellos mismos.
Lo que hago - no uso la subversión. Lo siento.
Ellos (los desarrolladores) obviamente no están de acuerdo con su evaluación de que es una característica crítica. No detuve la compañía en la que trabajo en este momento para usarla;) Personalmente descarto la subversión por esta razón exacta.
Obliterar no es una característica esencial de Subversion, porque en realidad rompe los principios básicos del control de versiones (que es: registrar todo el historial).
Y no es una característica esencial porque hay una solución para hacer esto de todos modos (usando svnadmin y filtrado).
Además, la característica está actualmente muy trabajada. Vea esta publicación para más detalles.
Obliterate viola los principios de control de versión que querrías tener. O bien no ahorraría espacio, o las etiquetas anteriores se romperían. No podría volver a una versión anterior verdadera si hubiera eliminado algún archivo.
En cuanto a su comentario sobre el crecimiento del repositorio ... Cualquier repositorio crecerá de manera lineal con el tamaño de los cambios a lo largo del tiempo. Ese es el punto central de un sistema de control de fuente. Si no necesita poder rastrear versiones anteriores, ¿por qué no limitarse a una carpeta compartida en algún lugar?
Todo el punto del control de código fuente es tener un historial completo de cómo se ve su repositorio. El comando obliterate anula este propósito del control de código fuente, y es un error en todos los sistemas de control de versiones que lo tienen.
SVN tiene una copia barata y una bifurcación barata que no requiere una copia completa del archivo, solo los bits modificados. Su depósito central suele ser de un tamaño muy manejable, lo que hace innecesaria esta característica errónea.
Utilizo varios sistemas de control de versiones desde hace unos 15 años y nunca necesité una característica como esta.
Me pregunto cuáles son las razones por las que quieres esa característica:
- espacio de disco? Difícil de creer teniendo en cuenta el precio del espacio en disco
- comprometido una contraseña para el control de versiones? Pues eso te enseñará. Ve y cambia la contraseña
- ¿La velocidad del repositorio? No suena así, pero si considerara un sistema completamente diferente con un rendimiento supuestamente mejor.
Viola el significado de control de fuente.
El control de fuente se trata de poder restaurar un estado anterior. Si elimina un archivo de forma permanente, no podrá hacerlo.
OTOH no sé VSS por lo que podría haber entendido mal "eliminar de forma permanente"