Почему не уничтожить существенную особенность Subversion?
Уже несколько лет я жду, когда в Subversion появится функция "удалить навсегда" (уничтожить). Я не решаюсь перейти на Subversion (из Visual SourceSafe:p), потому что я считаю, что это важная функция, так как в противном случае я ожидаю, что хранилище будет расти без остановки. Однако по той или иной причине эта функция откладывается снова и снова. Поэтому я начинаю задаваться вопросом, есть ли какая-то другая особенность или обходной путь, который делает функцию облитерации ненужной.
Что вы делаете, когда хотите сжать центральный репозиторий SVN?
Пример 1: я захожу в большую стороннюю библиотеку, и через несколько недель я понимаю, что она не подходит для моих нужд. Я не хочу, чтобы это навсегда сохраняло и создавало резервные копии такого большого количества данных.
Пример 2: у меня есть 10 версий 10 больших сторонних библиотек в хранилище, но я использую только самые последние версии.
Пример 3: я случайно зарегистрировал секретную информацию (как предложил Mr. Boy).
Пример 4: Я случайно зарегистрировал несколько больших файлов, которые никогда не предназначались для помещения в хранилище.
13 ответов
Существует довольно много дискуссий о svn obliterate на проблемном билете на сайте Apache Subversion, большая часть которого заканчивается примерно в 2008 году. Кажется, есть общее согласие, что это хорошая возможность, хотя его использование должно быть редким.
Есть две основные причины этого хотеть.
Во-первых, проверка конфиденциальной информации может быть проблемой. Оставлять его там, удаленным, не обязательно вариант, в зависимости от уровня конфиденциальности и открытости хранилища.
Во-вторых, регистрация большого количества вещей, которые не должны быть проверены, может резко увеличить размер хранилища. Дисковое пространство обычно дешевое в наше время, но оно не безгранично, и существуют другие способы, которыми файловое пространство может иметь значение. Если необходимо отправить репозиторий по сетевому соединению, это дополнительное время, которое может или не может быть важным. Реальные преимущества могут быть в том, что вы можете записать компакт-диск или DVD-диск, содержащий весь репозиторий.
Следовательно, это полезная возможность, которая в настоящее время выполняется путем выгрузки, фильтрации и перезагрузки хранилища. Согласно сообщениям, которые я видел, это подвержено ошибкам, может быть медленным и требует закрытия хранилища.
Очевидно, что это не высокоприоритетная особенность для команды Subversion, учитывая, что на протяжении нескольких лет нужно, чтобы кто-то сделал работу, чтобы придумать дизайн и реализовать его. В конце концов, это должно быть сделано очень редко, и есть обходной путь. Тем не менее, любой, кто хочет проделать большую работу над Subversion, может предоставить патч, который (при достаточно хорошем качестве), вероятно, будет реализован.
Это нарушает смысл контроля источников.
Контроль исходного кода - это возможность восстановить предыдущее состояние. Если вы удалите файл навсегда, вы не сможете.
OTOH я не знаю VSS, поэтому я мог неправильно понять "удалить навсегда"
Очевидная причина этого заключается в том, что разработчики думают, что это в конечном итоге ухудшит SVN - счастье, которое вы испытываете, когда удаляете ненужные вещи, будет значительно уменьшено вашим гневом, когда вы случайно уничтожите что-то и ваш / багажник пропадет.
FogBugz ведет себя точно так же, и в их случае, я полагаю, что он полностью разработан, защищая пользователей от самих себя.
Уничтожение нарушает принципы контроля версий, которые вы хотели бы иметь. Либо вы не сэкономите место, либо предыдущие теги будут повреждены. Вы не сможете вернуться к настоящей предыдущей версии, если удалили какие-либо файлы.
Что касается вашего комментария о расширении хранилища... Любое хранилище будет расти линейно с размером изменений с течением времени. В этом весь смысл системы контроля версий. Если вам не нужно отслеживать предыдущие версии, то почему бы просто не зайти куда-нибудь в общую папку?
Цитирование Subversion Obliterate, забытая особенность, состоит из трех компонентов: вопрос, проблема, причина и решение. Поскольку вы начали с вопроса к решению, я начну с этого.
Решение
Как вы заметили, отличного решения не существует. Особенно, если вы имеете дело с большим корпоративным репозиторием, поскольку решение становится тем сложнее, чем больше становится репо. Есть функция, называемая dump / filter, с помощью которой вы можете очистить репо от ненужных вам вещей, но это не так просто, не так быстро и ненадежно.
В команде svn было предпринято небольшое усилие (следите за темой), чтобы получить возможность уничтожения после 2008 года, но эта попытка умерла тихой смертью.
Эта проблема
В статье, о которой я упоминал в начале, на самом деле есть хороший список случаев использования, когда понадобится облитерирующая команда, а в ветке проблемы 516 разработчики фактически признали ее достоинства.
Увы, сейчас кажется, что уже слишком поздно; настоящая причина, по которой он никогда не был добавлен позже, заключалась в том, что теперь его практически невозможно реализовать, поскольку он подключается к коду на самом фундаментальном уровне (см. также ссылку на небольшие усилия в разделе "Решение").
Из записи FAQ:
Редакции - это неизменные деревья, которые строятся друг на друге. Удаление ревизии из истории вызовет эффект домино, создав хаос во всех последующих ревизиях и, возможно, сделает недействительными все рабочие копии.
Причина
Проблема заключается в том, что изначально уничтоженная особенность была отклонена, поскольку она не соответствовала принципу истинного контроля версий.
Опять из записи FAQ:
Как полностью удалить файл из истории репозитория? Существуют особые случаи, когда вы можете уничтожить все доказательства файла или коммита. (Возможно, кто-то случайно передал конфиденциальный документ.) Это не так просто, потому что Subversion специально разработана, чтобы никогда не потерять информацию.
тем не мение
Я работал с SVN для многих клиентов с большими командами и большими проектами, и в принципе у меня никогда не было настоящей проблемы. Да, упомянутые варианты использования требуют уничтожения, но пока я не уверен, что это проблема, которая возникает у вас снова и снова, куда бы вы ни пошли. Конечно, природа этой конкретной проблемы заключается в том, что вы должны совершить ошибку только один раз, и она не может быть исправлена должным образом.
Можно уменьшить размер хранилища SVN, выполнив дамп и загрузку. По сути, если вы говорите, что никогда не хотите возвращаться к чему-то более чем двухлетнему возрасту, можно выгрузить репозиторий, отфильтровать по времени, а затем перезагрузить дамп. Желание избавиться от одного файла из-за его размера - это, вероятно, признак того, что файл изначально не принадлежал системе управления исходным кодом.
Поскольку удаление данных из репозитория нарушает основную предпосылку контроля источников, то есть возможность воспроизводить все предыдущие состояния и изменения в дереве исходных текстов. Если вы хотите стереть что-то из-под контроля версий, вы, скорее всего, "делаете это неправильно", как говорится.
Существует несколько сценариев, которые помогают стирать данные. Следуйте этой ветке списка рассылки для получения дополнительной информации.
Это трудный способ сделать это, поскольку суть контроля версий заключается в том, чтобы не потерять данные, а удалить их навсегда. Но если вы подрезаете один раз в год или что-то в этом роде, это можно сделать.
Я использую различные системы контроля версий уже около 15 лет и никогда не нуждался в подобной функции.
Интересно, по каким причинам вы хотите эту функцию:
- дисковое пространство? Трудно поверить, учитывая цену дискового пространства
- отправил пароль для контроля версий? Ну, это тебя научит. Иди и смени пароль
- скорость работы репозитория? Звучит не так, но если бы я рассматривал совершенно другую систему с предположительно лучшей производительностью.
Весь смысл управления исходным кодом состоит в том, чтобы иметь полную историю того, как выглядит ваш репозиторий. obliterate Команда побеждает эту цель контроля исходного кода, и она является ошибкой во всех системах контроля версий, которые ее имеют.
SVN имеет дешевое копирование и дешевое ветвление, которое не требует полной копии файла - только измененные биты. Его центральный репозиторий, как правило, очень управляем по размеру, что делает ненужной эту неудачу.
В последний раз я проверял, что он предназначен для использования в качестве функции ADMIN, и администратор может в любом случае вывести дамп /filter/broken_workaround и удалить историю. Что касается контрольного журнала, это не меняет текущую цитату. Это сделало бы это менее ужасным, если бы что-то абсолютно необходимо удалить.
Svnadmin облитерации - одна из самых востребованных функций, разработчики наконец признают, что она должна существовать (наконец-то! Через 8 лет!!!). И публичность этого не существует, отгоняет пользователей от SVN.
К сожалению, мне пришлось нелегко узнать об этой "недостающей функции". С каких это пор базовая функциональность становится функцией? Новые пользователи начинают слышать об этом и избегают SVN. Что касается меня, я сейчас использую Git.
Не нравится мое мнение? Линус назвал разработчиков SVN дебилами, и вся централизованная система имела недостатки. Я доверяю Линусу как истинному эксперту, а именно Он знает об источнике.
Уничтожение не является существенной особенностью Subversion, потому что оно фактически нарушает основные принципы контроля версий (а именно: запись всей истории).
И это не является существенной функцией, потому что есть обходной путь, чтобы сделать это так или иначе (используя svnadmin и фильтрацию).
Кроме того, эта функция в настоящее время интенсивно работает. Смотрите этот пост для деталей.
Что я делаю - не использую подрывную деятельность. Сожалею.
Они (разработчики) явно не согласны с вашей оценкой того, что это критическая особенность. Не помешала компании, в которой я работаю, использовать ее;) Лично я исключаю подрывную деятельность именно по этой причине.