Почему не уничтожить существенную особенность Subversion?

Question

Уже несколько лет я жду, когда в Subversion появится функция «удалить навсегда» (уничтожить).Я не решаюсь перейти на Subversion (из Visual SourceSafe: p), потому что я считаю, что это существенная особенность, так как в противном случае я ожидаю, что хранилище будет расти нестабильно.Однако по той или иной причине эта функция откладывается снова и снова.Поэтому я начинаю задаваться вопросом, есть ли какая-либо другая особенность или обходной путь, который делает функцию облитерации ненужной.

Что вы делаете, когда хотите сжать центральный репозиторий SVN?

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

Пример 2 : у меня есть 10 версий 10 больших сторонних библиотек в хранилище, но я использую толькопоследние версии.

Пример 3 : Я случайно проверил конфиденциальную информацию (как предложено John ).

Пример 4 : я случайно зарегистрировал несколько больших файлов, которые никогда не предназначались для помещения в хранилище.

Answer 1

Существует довольно много дискуссий о svn obliterate в заявке о проблеме на сайте Apache Subversion , большая часть которого заканчивается в 2008 году. Кажется, существует общее согласие, что это хорошая возможность иметь , хотя его использование должно быть редким.

Есть две основные причины хотеть этого.

Во-первых, проверка конфиденциальной информации может быть проблемой. Оставлять его там, удаленным, не обязательно вариант, в зависимости от уровня конфиденциальности и уязвимости хранилища.

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

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

Очевидно, что это не высокоприоритетная функция для команды Subversion, учитывая, что на протяжении нескольких лет нужно, чтобы кто-то выполнил работу, чтобы придумать дизайн и реализовать его. В конце концов, это должно быть сделано очень редко, и есть обходной путь. Однако любой, кто хочет проделать большую работу над Subversion, может предоставить исправление, которое (если оно будет достаточно хорошего качества), вероятно, будет реализовано.

Answer 2

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

OTOH я не знаю VSS, поэтому я мог неправильно понять "удалить навсегда"

Answer 3

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

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

Answer 4

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

Что касается вашего комментария о расширении хранилища ... Любое хранилище будет расти линейно с размером изменений со временем. В этом весь смысл системы контроля версий. Если вам не нужно отслеживать предыдущие версии, то почему бы просто не зайти куда-нибудь в общую папку?

Answer 5

Цитирование Subversion Obliterate, забытая особенность , вопрос состоит из трех компонентов: проблема , причина и решение . Поскольку вы начали с вопроса к решению, я начну с этого.

Решение

Как вы заметили, отличного решения не существует. Особенно, если вы имеете дело с большим корпоративным репозиторием, поскольку решение становится тем сложнее, чем больше становится репо. Есть функция под названием dump / filter , с помощью которой вы можете очистить репо от ненужных вам вещей, но это не так просто, не так быстро и ненадежно.

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

проблема

В статье, о которой я упоминал в начале, на самом деле есть хороший список случаев использования, когда требуется облитерирующая команда, а в ветке 516 разработчики фактически признали ее достоинства.

Увы, сейчас слишком поздно; настоящая причина, по которой он никогда не был добавлен позже, заключалась в том, что теперь его практически невозможно реализовать, поскольку он подключается к коду на самом фундаментальном уровне (см. также ссылку small усилия в разделе Solution).

Из записи FAQ :

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

Причина

Проблема в том, что изначально уничтоженная функция была удалена, поскольку она не соответствовала принципу истинного контроля версий.

Снова из записи FAQ :

Как полностью удалить файл из истории хранилища? Есть особые случаи, когда вы можете уничтожить все доказательства файла или коммита. (Возможно, кто-то случайно передал конфиденциальный документ.) Это не так просто, , потому что Subversion специально разработан, чтобы никогда не терять информацию .

Однако

Теперь я работал с SVN для многих клиентов с большими командами и более крупным проектом, и в принципе у меня никогда не было настоящей проблемы. Да, упомянутые варианты использования требуют уничтожения, но пока я не уверен, что это проблема, которая возникает у вас снова и снова, куда бы вы ни пошли. Конечно, суть этой конкретной проблемы заключается в том, что вы должны совершить ошибку только один раз, и ее нельзя исправить должным образом.

Answer 6

Существует несколько сценариев, которые помогают стирать данные. Следуйте этой ветке списка рассылки для получения дополнительной информации.

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

Answer 7

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

Answer 8

Я использую различные системы контроля версий уже около 15 лет и никогда не нуждался в подобной функции.

Интересно, почему вы хотите эту функцию:

• дискового пространства? Трудно поверить, учитывая цену дискового пространства
• отправил пароль для контроля версий? Ну, это тебя научит. Зайдите и смените пароль
• скорость работы хранилища? Звучит не так, но если бы я рассматривал совершенно другую систему с предположительно лучшей производительностью.

Answer 9

Поскольку удаление данных из хранилища нарушает основную предпосылку контроля источников, то есть возможность воспроизводить все предыдущие состояния и изменения в дереве исходных текстов. Если вы хотите стереть что-то из-за контроля версий, вы, как говорится, «Делаете это неправильно».

Answer 10

Весь смысл управления исходным кодом состоит в том, чтобы иметь полную историю того, как выглядит ваш репозиторий. Команда obliterate побеждает эту цель управления исходным кодом, и она является ошибочной во всех системах контроля версий, которые ее имеют.

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