oragrafaddyy,

Ну ка, что будешь делать в таком случае? Приходишь к заказчику с одной флешкой со скриптами, инета нет . Тебе надо попробовать погонять скрипты в разных вариациях, периодически в них что-то подпиливая. Причем эти подпиливания нужно сохранить и принести к себе на работу, чтобы выбрать лучшее. Твои действия с свн? Копипаст по папкам? Локальный реп на флешке? Ок. А потом на работе у себя как сливать в центральный? опять копипаст из одного места в другое
Только поработав с гит, я понял силу веток и мерджей.

В моем примере решения (см. выше) разумеется есть минусы

Самый очевидный: рассинхронизация номеров коммитов на флешке и в центральном репозитории.
Но ведь с репозиторием на флешке мы больше работать не будем ? За этим сливаем
изменения в центральный репозиторий ?

А комментарии при коммите указываем наверное за тем, чтобы в случае чего, по ним
что-то найти, а не по номерам коммитов ?

oragrafaddyy,

1. Я хочу принести историю изменений потом в офис. Коммитить или нет и что конкретно коммитить в центральный реп - я решу потом.
2. Вопрос был не в том, что ты в офисе делать будешь. Вопрос был в том, как ты сохранишь историю своих изменений у заказчика.
3. Про функциональность и вынос в модули - у меня есть набор sql-скриптов. Какая там функциональность и модули? Но их тоже скомпоновать и написать можно сильно по-разному.

Я не понял, почему есть вопрос " как ты сохранишь историю своих изменений у заказчика "
Откуда он вообще берется ?
В чем вообще здесь проблема ?

Да, создается локальный репозиторий, того же SVN

Создается где угодно. Хоть на флешке, хоть на сервере/компе у клиента.
Потом достаточно его выгрузить командой svnadmin dump в файл
этот файл принести с собой.

Дальше из него можно создать
1) Отдельный репозиторий на своем ноутбуке, скажем
2) Перенести историю прямо из файла в центральный репозиторий

3) При желании, слить какую-то версию какого-то файла "от заказчика"
с таким же или другим файлом из центрального репозитория.

В чем вопрос, я не понимаю ?

Да, в Git это штатный функционал, это распределенная система,
но в SVN эта задача решается тремя командами, можно и двумя, но лучше тремя ;-)

oragrafaddyy,

3. Про функциональность и вынос в модули - у меня есть набор sql-скриптов. Какая там функциональность и модули? Но их тоже скомпоновать и написать можно сильно по-разному.

SQL скрипты - текстовые файлы, так ?
Любая система "сборки" текстовых файлов, любая шаблонная система вам подойдет.

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

oragrafaddyy,

я правильно понимаю, что ты:
1. делаешь из дампа центральный реп на ноуте и коммитишь туда все изменения?
2. приходишь в офис и сливаешь эти изменения в центральный реп в офисе?


Да, почти.
Я так не делаю, ибо вижу другое решение задачи.

Но если отталкиваться от того, что сформулировано в условии задачи - то все верно.
Так делать можно. Можно и с SVN иметь хоть сколько угодно
репозиториев, хоть миллиард.

Один у заказчика, один на флешке, другой на ноутбуке, третий на сервере.

Минус только в том, что замучаешься синхронизировать, не предназначена
для этого система.

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

oragrafaddyy,

я правильно понимаю, что ты:
1. делаешь из дампа центральный реп на ноуте и коммитишь туда все изменения?
2. приходишь в офис и сливаешь эти изменения в центральный реп в офисе?

Я никогда не понимал, почему Git ставят в заслугу "вы можете работать с ним без интернета, например, в самолете"
типа потому, что это децентрализованная система. Да, децентрализованная, да, она на это рассчитана.
Но с SVN все тоже самое можно делать, с некоторыми оговорками, но их мало кто заметит.

У меня на компьютере есть локальный /не сетевой / без сервера / без инсталяции репозиторий
для экспериментов. Я им пользуюсь, в основном, как "многоуровневым Undo".

Мне так удобнее, конечно можно и по-другому работать, вопрос в том, какие + и - у подходов ;-)

oragrafaddyy,

я правильно понимаю, что ты:
1. делаешь из дампа центральный реп на ноуте и коммитишь туда все изменения?
2. приходишь в офис и сливаешь эти изменения в центральный реп в офисе?


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

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

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

Вся история сохранится, но разумеется, поскольку в SVN номера
коммитов глобальны на уровне репозитория, после заливки
дампа одни и те же изменения будут иметь разные номера коммитов
в ноутбучном репозитории и репозитории сервера. При желании,
можно и это побороть ;-)

Схема с дампом плохо (мягко скажем) работает для двухсторонней репликации,
а если все изменения и вся история идут по цепочке все время в одну
и ту же сторону, тогда она вполне рабочая.

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

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

Может возникнуть некая путанница при сливе изменений туда-сюда,
все таки это хак, нештатное использование системы.

Но все решаемо, если все изменения брать / заливать
в свою ветку (директорию) и если с этой веткой
работает только один человек.

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