Нужно ли удалять старый / старый / неиспользуемый код из репозитория управления исходным кодом? - PullRequest
13 голосов
/ 12 мая 2010

Я сталкивался с этим в нескольких проектах. По мере развития базы кода некоторые библиотеки, приложения и компоненты будут заброшены и / или объявлены устаревшими.

  1. Большинство людей предпочитают хранить их внутри. Обычный аргумент в том, что код на самом деле не занимает никакого места, его можно оставить в покое, пока он снова не понадобится.
    Таким образом, хранилище медленно превращается в выгребную яму устаревшего кода, где трудно что-либо найти.
    Еще один аргумент в пользу сохранения старого кода заключается в том, что у новых людей не будет соблазна попробовать реализовать что-то, что было реализовано в прошлом, но не вполне сработало.

  2. Некоторые люди удаляют старый код, поскольку он создает беспорядок, вызывает больше вопросов для новых людей, и вы в любом случае можете восстановить любой старый снимок базы кода.
    Однако вы не всегда можете найти старый код, если не знаете, где искать, поскольку ни одна из известных мне (распространенных) VCS не предлагает поиск по всему хранилищу, включая все исторические ревизии, и единственный способ поиска по старым файлам. проверить версию, в которой существует удаленный файл.

Каким будет хороший подход к управлению хранилищем?

Ответы [ 6 ]

16 голосов
/ 12 мая 2010
  1. Убери это. Это беспорядок - если это не служит точке или сбивает с толку, лучше уйти.
  2. git grep или аналогичный.
10 голосов
/ 12 мая 2010

Неиспользуемый код занимает место в сознании людей . Неиспользуемый и ненужный код загромождает ментальные модели людей и затрудняет понимание того, для чего все в хранилище ( "о, не беспокойтесь об этом, мы его больше не используем" ). В этих случаях полезно удалить код из репозитория, но может быть полезно документировать (в вики или подобном), какие старые приложения / компоненты / и т. Д. Были удалены, почему они были удалены и где их можно найти.

3 голосов
/ 12 мая 2010

У нас есть ветка, в которую мы копируем устаревшие библиотеки и проекты, прежде чем удалять их из транка.

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

Хотя, если честно, я не могу вспомнить время, когда мы действительно вернулись к старому проекту и воскресили его ...

2 голосов
/ 19 июня 2011

Удали это. Если у него нет тестов, вы даже не знаете, работает ли он до сих пор. Если есть какие-то части, которые полезны, вытащите их. Старый код всегда сдерживает вас. Если вы не можете легко восстановить функциональность, которая была у вас в старом коде, либо вы не должны были заменить ее, либо ваш новый код бесполезен.

Для проектов, в которых участвуют новые участники: чем больше у вас кода, тем больше у них уходит времени на изучение веревок и тем сложнее вносить изменения. Cruft только собирается вызвать путаницу. Старый код будет иметь значение только для тех, кто был рядом, когда он работал.

Для моих личных проектов у меня есть привычка переносить неудачные идеи в папку _archive. Эта папка используется только для справки и последующих попыток. Если бы проекты для массового потребления были бы немедленно удалены, чтобы минимизировать базовый размер кода.

2 голосов
/ 12 мая 2010

В моем личном репозитории Subversion, который полон заброшенных проектов, я перемещаю вещи, которые больше не хочу видеть, в каталог / attic. Я мог бы также удалить их, но за счет одного дополнительного каталога в корне мультипроекта мне не нужно искать в истории, когда я хочу найти то, что, как мне показалось, больше не нужно. 1001 *

1 голос
/ 12 мая 2010

Разветвите оригинальный код. Очистить мастер / багажник и будущие релизы.

Устаревший код предназначен для тех, кому он может или не нужен.

Что касается поиска файла, я знаю, что git может это сделать. Но в общем случае вы просто просматриваете журналы коммитов в любом хранилище

git log --all -- legacyfile

Тогда найдите файл в ветке:

git branch --contains $filehash

edit Просто хотел добавить, что в нескольких случаях мне приходилось возвращаться и искать файлы в других проектах, которые были значительно старыми, 5 или 10 лет или около того. Я был очень благодарен, что это все еще было там.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...