Какую выбрать систему управления версиями для обычных файлов и документов?
Платформа Win7/8/10.
Нужна система, программа или дополнение к стандартному проводнику Windows, в которой бы велся архив и учет изменений определенных файла/ов или обычных документов.
В идеале система сама видит, что такой-то файл изменился, при этом она отправляет прошлую копию файла в архив и запрашивает у пользователя причину текущих изменений файла для логирования и истории.
Т.е. нужно что-то вроде стандартных теневых копий, но при этом напротив каждой копии указаны изменения (вводимые пользователем) с информацией, что конкретно изменили и зачем.
И самый кайф, если такая софтина еще и будет работать с файлами по аналогии со снэпшотами виртуальной машины (с деревом различных версий файла и с возможностью сделать merge).
Посоветуйте что-нибудь, плз, а то на мои запросы поисковики предлагают мне "контроль программного кода" и т.п. подобное, что совсем не то, что мне надо.
UPD. Подробности и описание
Глобально, проблема следующая.
Есть некий купленный софт, который хранит свои данные в SQLite или в Excel-файлах (xlsx) (можно делать экспорт).
Массивы очень огромные, + постоянно пополняются новыми данными, при этом в большинстве случаев работа ведется только с о-о-очень маленькой частью БД.
Возникла идея разделить такую БД на "горячую" и "холодную", периодически сбрасывая ненужные данные в "холодную" часть.
Делать это достаточно вручную, ни о какой автоматизации речи не стоит.
Иными словами, достаточно просто ручками 1 раз в неделю делать копию текущий БД, удаляя в свежей копии "холодные" данные.
Итого, в последней копии, с которой ведется работа — "горячие" данные, в архивных копиях — "холодные" данные. Так решается задача и бэкапа, и "облегчения" текущей БД.
Но при этом очень нужна система учета версий "холодных" копий БД, т.к. периодически они тоже нужны в работе.
Cофт проприетарный, к начинке софта доступа, естественно, нет. То, что он на SQLite — лишь уверенное предположение, т.к. в подпапке с программой есть файлик "\RestoreBD\sqlite3.exe" (он запускается через обычный батник для реанимации и пересборки базы).
Далее, при попытке открыть файл БД через SQLiteStudio — файл с БД открывается нормально, несмотря на проприетарное расширение в имении файла.
Вся структура в SQLiteStudio видна, ничего не обфусицированно, даже столбцы названы понятными переменными, и все данные читаются в том же виде, что и в проприетарном софте. Т.е. файл с базой отнюдь не закрыт наглухо и не зашифрован (только расширение файла поменяно).
Данный проприетарный софт в единицу времени работает с одной БД, т.е. физически — с одним файлом БД. Поэтому мне и надо физически разделить БД на несколько файлов, чтобы работать с базой весом в несколько мегабайт, чем в несколько гигабайт. При этом важно не забыть, где, что и в каком виде хранится. Для этого и нужна какая-та система учета версий обычных файлов.
Сейчас в БД порядка 140 таблиц, в каждой из которых 126 столбцов, и 100 до 300 000 записей.
Из каждой таблицы мне нужно 0,01%-10% данных, которые я получаю выборкой.
Я хочу сохранять выборку отдельно, и работать только с ней ("горячая база"), оставив остальное в "холодной" базе.
Периодически я делаю новую выборку, и работаю с ней.
Если я ручками сохраняю свою выборку, то начинают плодиться файлы "2017-03-10, проект такой-то, выборка такая-то" или "2017-03-17, проект такой-то, удалены такие то данные", что при достижении таких файлов больше 3-5 штук уже приводит к путанице и попытке разобраться, где конкретно содержатся определенные, нужные в данный момент времени, данные.
В итоге, я отказался от такого варианта ручного копирования и наименования файлов, и работаю с файлом в 1,5 Гига, что очень сказывается на производительности.
Т.е чтобы при любом изменении файла в указанной директории работа пользователя принудительно блокировалась, и появлялось окно с просьбой ввести причину изменения?
АртемЪ: Я думал об этом. Это, конечно, вряд ли будет удобным в работе, т.е. нужны какие-то настройки у такой системы. Типа, задавать вопрос раз в час / в день / в неделю / при сохранении файла.
В первую очередь, мне достаточно "ручного" режима, когда я делаю копию какого-то файла, и старый отправляется в специальную папочку с версиями и с определенными комментариями.
При этом возникает проблема контроля версия файла при внесении изменений в какой-то старый файл (где есть те данные, которых нет в последнем, обновленном файле).
Вообще, глобально, проблема следующая.
Есть некий купленный софт, который хранит свои данные в SQLite или в Excel-файлах (xlsx) (можно делать экспорт).
Массивы очень огромные, + постоянно пополняются новыми данными, при этом в большинстве случаев работа ведется только с о-о-очень маленькой частью БД.
Возникла идея разделить такую БД на "горячую" и "холодную", периодически сбрасывая ненужные данные в "холодную" часть.
Делать это достаточно вручную, ни о какой автоматизации речи не стоит.
Иными словами, достаточно просто ручками 1 раз в неделю делать копию текущий БД, удаляя в свежей копии "холодные" данные.
Итого, в последней копии, с которой ведется работа — "горячие" данные, в архивных копиях — "холодные" данные. Так решается задача и бэкапа, и "облегчения" текущей БД.
Но при этом очень нужна система учета версий "холодных" копий БД, т.к. периодически они тоже нужны в работе.
Не проще ли сделать так -
Две базы полная(холодная) и урезанная(горячая)
Работаем с горячей, но если надо подключена и холодная.
Раз в неделю/месяц/или другой период сбрасываем синхронизируем то что надо скриптом или руками.
Не пойму зачем отслеживать?
Cофт проприетарный, к начинке софта доступа, естественно, нет. То, что он на SQLite — лишь уверенное предположение, т.к. в подпапке с программой есть файлик "\RestoreBD\sqlite3.exe" (он запускается через обычный батник для реанимации и пересборке базы).
Далее, при попытке открыть файл БД через SQLiteStudio — файл с БД открывается нормально, несмотря на проприетарное расширение в имении файла.
Вся структура в SQLiteStudio видна, ничего не обсуфицированно, даже столбцы названы понятными переменными, и все данные читаются в том же виде, что и в проприетарном софте. Т.е. файл с базой отнюдь не закрыт наглухо и не зашифрофан (только расширение файла поменяно).
Данный проприетарный софт в единицу времени работает с одной БД, т.е. физически — с одним файлом БД. Поэтому мне и надо физически разделить БД на несколько файлов, чтобы работать с базой весом в несколько мегабайт, чем в несколько гигабайт. При этом важно не забыть, где, что и в каком виде хранится. Для этого и нужна какая-та система учета версий обычных файлов.
АртемЪ:
Сейчас в БД порядка 140 таблиц, в каждой из которых 126 столбцов, и 100 до 300 000 записей.
Из каждой таблицы мне нужно 0,01%-10% данных, которые я получаю выборкой.
Я хочу сохранять выборку отдельно, и работать только с ней ("горячая база"), оставив остальное в "холодной" базе.
Периодически я делаю новую выборку, и работаю с ней.
Если я ручками сохраняю свою выборку, то начинают плодиться файлы "2017-03-10, проект такой-то, выборка такая-то" или "2017-03-17, проект такой-то, удалены такие то данные", что при достижении таких файлов больше 3-5 штук уже приводит к путанице и попытке разобраться, где конкретно содержатся определенные, нужные в данный момент времени, данные.
В итоге, я отказался от такого варианта ручного копирования и наименования файлов, и работаю с файлом в 1,5 Гига, что очень сказывается на производительности.
zamboga: копии БД бинарные или текстовые? Если бинарные -- дельту изменений вы видеть там не будете. Если текстовые -- то есть шанс. Но надо понимать, что дамп БД, даже в текстовом виде -- это не конфиги и не исходники, и даже не текстовый документ, так что при определёных условиях у любых системы контроля версий может ехать крыша (например, почему-то поменяется порядок сортировки таблиц при выгрузке в дамп), и тогда дельты тоже не будет. Точнее, технически она будет, конечно, но будет абсолютно бесполезна.
А комментарии к версии, конечно, работать при этом будут.
Cофт проприетарный, к начинке софта доступа, естественно, нет. То, что он на SQLite — лишь уверенное предположение, т.к. в подпапке с программой есть файлик "\RestoreBD\sqlite3.exe" (он запускается через обычный батник для реанимации и пересборки базы).
Далее, при попытке открыть файл БД через SQLiteStudio — файл с БД открывается нормально, несмотря на проприетарное расширение в имении файла.
Я затрудняюсь сказать, бинарный или текстовый файл, в в этом я уже не спец. Но вся структура в SQLiteStudio видна, ничего не обфусицированно, даже столбцы названы понятными переменными, и все данные читаются в том же виде, что и в проприетарном софте. Т.е. файл с базой отнюдь не закрыт наглухо и не зашифрован (только расширение файла поменяно).
Данный проприетарный софт в единицу времени работает с одной БД, т.е. физически — с одним файлом БД. Поэтому мне и надо физически разделить БД на несколько файлов, чтобы работать с базой весом в несколько мегабайт, чем в несколько гигабайт. При этом важно не забыть, где, что и в каком виде хранится. Для этого и нужна какая-та система учета версий обычных файлов.
Касательно ваших вопросов выше про Subversion: для SVN не нужен апач. Апач нужен только если вы веб-интерфейс собираетесь использовать к SVN. Нужен только svnserve (т.е. SVN сервер) и SVN-клиент (Например, GUI-шный TortoiseSVN). Но с SVN могут начаться тормоза, учитывая размеры ваших файлов. С другой стороны, вы ничего не теряете, если попробуете.
Репозиторий будет нужен в обязательном порядке -- это ж и есть место хранения всех ваших файлов с их версиями ;-) Но учитывая, что у вас бинарные файлы с БД, никакой дельты SVN высчитывать не будет. Так что планируйте сразу объём диска под репозиторий как сумму размеров всех копий и версий БД на N месяцев/лет вперёд.
Какую выбрать систему управления версиями для обычных файлов и документов?
Смешались в кучу кони, люди... Можно использовать встроенные возможности применяемых систем. Кроме системы отслеживания изменений включённых в Windows, в MS Office файлах можно включить отслеживание изменений с добавление дополнительной информации (кто, когда, зачем). В СУБД можно делать резервные копии полные или разностные, как в отдельный файл, так в один и тот же — можно будет отслеживать, если указать, кто, когда, зачем.
Возникла идея разделить такую БД на "горячую" и "холодную",
1. Сегментирование мне не подойдет, софт проприетарный, к начинке софта доступа, естественно, нет. То, что он на SQLite — лишь уверенное предположение, т.к. в подпапке с программой есть файлик "\RestoreBD\sqlite3.exe" (он запускается через обычный батник для реанимации и пересборке базы).
Далее, при попытке открыть файл БД через SQLiteStudio — файл с БД открывается нормально, несмотря на проприетарное расширение в имении файла.
Также данный проприетарный софт в единицу времени работает с одной БД, т.е. физически — с одним файлом БД. Поэтому мне и надо физически разделить БД на несколько файлов, чтобы работать с базой весом в несколько мегабайт, чем в несколько гигабайт. При этом важно не забыть, где, что и в каком виде хранится. Для этого и нужна какая-та система учета версий обычных файлов.
2. Про MS Office. Если вы имеете в виду режим включенный режим рецензирования, то он не подойдет. Идея в том, чтобы в текущий момент времени оперировать таблицей размером в пару мегабайт, а не в пару гигабайт. Ну и потом, через Excel нам будет значительно менее удобно работать, чем через проприетарный софт, т.к. Excel используется как вспомогательный инструмент, куда на время копипастятся туда и обратно данные для какой-то обработки, которой нет в проприетарном софте. Поэтому постоянно использовать Excel, как замену БД — точно не вариант.
Простой
