Лучшие практики для управления версиями текстовых данных

Question

Каковы рекомендации по управлению версиями данных, содержащихся в нескольких больших (100 МБ +) файлах CSV?

Является ли SVN хорошим вариантом?

Обновление: После обсуждения нана какое-то время я чувствую, что это может быть лучшим вариантом: GZIP / Zip файл CSV, а затем добавить его в репозиторий.Таким образом, я бы сэкономил на головной боли управления версиями, не теряя при этом дискового пространства.Это, по крайней мере, так же хорошо, если не лучше, чем управление их версиями вручную.

Все еще ищем идеальное решение.

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

Answer 1

Это в значительной степени зависит от того, как вы намереваетесь использовать эти файлы.

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

Однако ...

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

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

Пища для размышлений ...

РЕДАКТИРОВАТЬ Кроме того, может быть проблема с diff, я не уверен, если SVN поддерживает diffна CSV, поэтому каждый раз, когда вы регистрируетесь в недрах SVN, он может полностью заменить старый файл (сохраняя старый для справки).Это может быстро занять много места на диске.

Answer 2

SVN ужасно медленный, потому что он передает все данные по сети. Попробуйте локальный репозиторий git или hg. Это только требует доступа к файлу, который должен быть намного быстрее, чем в сети. Оба типа репо также намного лучше справляются с перемещением файлов, переименованием файлов и слиянием. Кроме того, git может использовать «плагины» для поддержки других типов файлов, таких как объединение офисных документов (odf, doc и т. Д.).

В отличие от SVN, у вас есть только один скрытый каталог репозитория, содержащий сжатый репозиторий. SVN имеет .svn dir в каждом sub dir, содержащем последнее состояние файла (и другие вещи).

Некоторые случайные числа:

Предположим, что размер всех файлов (не информации репо) в хранилище составляет 100 МБ

• Проверка SVN займет от 200 до 250 МБ, все более старые версии должны быть перенесены с сервера SVN.
• Для репозитория git или hg потребуется 150 МБ (при условии, что файлы можно хорошо сжать), включая все версии файлов.

Это то, что мы испытали с SVN и git. Я использую HG (Mercurial) только изредка.

Что касается ответа MrEyes, я бы также предложил добавить некоторую информацию о версии в файл CSV или имя файла. Git определит переименование файла, включая изменения и т. Д.