¿Debería eliminarse el código anterior/heredado/no utilizado del repositorio de control de origen?

Question

He encontrado esto en múltiples proyectos. A medida que evoluciona la base de códigos, algunas bibliotecas, aplicaciones y componentes se abandonan y/o quedan obsoletos.

1. mayoría de las personas prefieren mantenerlos en. El argumento habitual es que el código realmente no toma ningún espacio, se puede dejar solo hasta que se necesite de nuevo.
   Así que un repositorio se convierte lentamente en un pozo negro de código heredado, donde es difícil encontrar algo.
   Otro argumento para mantener el viejo código es que la gente nueva no tendrá la tentación de intentar implementar algo que se implementó en el pasado, pero no funcionó del todo.

2. Algunas personas eliminan el código anterior, ya que crea confusión, genera más preguntas para las personas nuevas y, de todos modos, puede restaurar cualquier instantánea anterior de la base de códigos.
   Sin embargo, no siempre puede encontrar el código anterior si no sabe dónde buscar, ya que ninguno de los VCS (comunes) que conozco ofrecen búsquedas en todo el repositorio, incluidas todas las revisiones históricas, y la única forma de buscar en el los archivos antiguos son para verificar la revisión donde existe el archivo eliminado.

¿Cuál sería un buen enfoque para la gestión de repositorios?

Answer 1

1. Eliminarlo. Es desorden - si no sirve un punto o es confuso, es mejor que se vaya.
2. git grep o similar.

Answer 2

Tenemos una rama a la que copiamos las bibliotecas y proyectos obsoletos antes de eliminarlos de la troncal.

repo 
    +- trunk 
    +- tags 
    | +- old-code 
    |  +- project1 
    |  +- project2 
    |   ... 
    +- branches 

Aunque, para ser honesto, realmente no puedo pensar en un momento en que en realidad hemos vuelto a un viejo proyecto y lo resucitó ...

Answer 3

rama del código original. Limpiar el maestro/troncal y las versiones futuras.

El código heredado está ahí para quien lo necesite o no.

En cuanto a la búsqueda del archivo, sé que git puede hacer esto. Pero, en general, sólo una búsqueda en los registros de cometer cualquier repositorio

git log --all -- legacyfile 

A continuación, busque el archivo en la rama:

git branch --contains $filehash 

edición sólo quería añadir que en varias ocasiones he tenido una Necesita volver atrás y buscar archivos en otros proyectos que eran considerablemente antiguos, 5 o 10 años más o menos. Estaba muy agradecido de que todavía estuviera allí.

Answer 4

El código no utilizado ocupa espacio en las mentes de las personas. El código innecesario e innecesario atormenta los modelos mentales de las personas y hace que sea más difícil entender para qué está todo en el repositorio ("oh, no te preocupes por eso, ya no lo usamos").Es bueno borrar el código del repositorio en estas circunstancias, pero puede ser útil documentar (en una wiki o similar) qué aplicaciones/componentes/etc antiguos se han eliminado, por qué se eliminaron y dónde se pueden encontrar.

Answer 5

En mi repositorio personal de Subversion, que está lleno de proyectos abandonados, muevo cosas que no quiero ver más en un directorio/ático. También podría borrarlos, pero a costa de un directorio adicional en la raíz de múltiples proyectos, no tengo que buscar en la historia cuando quiero encontrar algo que pensé que ya no necesitaba.

Answer 6

Eliminarlo. Si no tiene pruebas, ni siquiera sabes si todavía funciona. Si hay algunas partes que sean útiles, extráigalas. El código antiguo siempre te detiene. Si no puede reconstruir fácilmente la funcionalidad que tenía en el código anterior, o bien no debería haberla reemplazado, o su nuevo código no es bueno.

Para proyectos que traen nuevos miembros: Cuantos más códigos tenga, más tiempo le tomará aprender las cuerdas, y más difícil será hacer cambios. Cruft solo causará confusión. El código antiguo solo tendrá sentido para aquellos que existían cuando funcionó.

Para mis proyectos personales, tengo la costumbre de mover ideas fallidas a una carpeta _archive. Esa carpeta solo sirve como referencia, e intentos posteriores. Si los proyectos de consumo masivo fueran eliminados inmediatamente para minimizar el tamaño de la base del código.