Тупой вопрос - как объяснить 50-летнему чайнику про SVN? Опции

[syoma]

Столкнулся с по-видимому непосильной задачей - как объяснить человеку, а точнее даже не одному, оставшимся в прошлом веке, как работает SVN (Точнее TortoiseSVN) и почему не надо архивировать и хранить версии всех своих файлов в той-же папке, что такое Коммит и Чекаут, и почему оно ничего не находит в екплорере?

Вроде как программисты, а вроде как и нет.

Может есть инструкция доходчивая на русском для тупых или опыт какой? У меня просто мыслей и нервов не хватает.

[Xenia]

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

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

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

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

ИМХО, приучить пользоваться новым инструментом можно двумя путями: тоталитарно-административным либо создать такие условаия, что "нужда сама заставит". И в этот момент подсказать правильный путь, объяснить, как пользоваться и то.

Какая нужда? Кто вообще читает этот "лист регистрации изменений"? Ради какой проверяющей инстанции он пишется?

[Corvus]

Достаточно будет просто сохранить проект на той стадии, до которой тот его довел.

Всё верно. Только как его сохранить? В восьми папках с названиями вроде "project_last_work_dd_mm_yyy", "project_test_work_dd_mm_yyy"? А если таких проектов несколько? Сколько времени у нового человека уйдёт, чтоб просто собрать последнюю версию. Про проследить что, когда и зачем добавлялось можно забыть сразу.

У нас, российских разработчиков, свой путь к технической сингулярности - с упором на индивидуала! А насаждение американской коллективизации в любом деле уже достало.

И результат на лицо! Я так понимаю, с Эльбруса под Патриот ОС пишете?

[_4afc_]

Всё верно. Только как его сохранить? В восьми папках с названиями вроде "project_last_work_dd_mm_yyy", "project_test_work_dd_mm_yyy"? А если таких проектов несколько? Сколько времени у нового человека уйдёт, чтоб просто собрать последнюю версию. Про проследить что, когда и зачем добавлялось можно забыть сразу.

Чужой старый код можно скомпилить только на томже компиляторе. И, возможно, при организации как у RST7 - что-то получится.

Помнится я писал код под Watcom_x86, затем портировал под Студию_ARM7, потом для обхода лицензии под GCC_ARM7, а затем под лицензионный ICC_ARM7. Этот код выполнял одни и теже действия, но из-за разных компиляторов приходилось его модифицировать в каждом случае под конкретное описание прерываний и т.п.

А вот пример про SVN в руках у дурака: система на QNX шлёт Ethernet пакеты в системы на Linux и Windows. Исходники всех трёх систем лежат в общем SVN. Начальник - разработчик Windows.
1. Я, как разработчик под QNX передаю бумажный документ описывающий в виде таблицы содержимое пакета, длинн и форматов данных всем участникам.
2. Происходит успешная стыковка QNX - Linux. Система под Windows не понимает пакеты от QNX.
3. Windows-Начальник составляет по документу Etable.h файл, кладёт его в SVN и требует чтоб все компилили именно с ним.
4. Система под QNX со скомпилённым Etable.h стыкуется с системой под Linux со скомпилённым Etable.h. Система под Windows не понимает пакеты от QNX.
5. Windows-Начальник говорит что програмисты QNX и Linux не умеют пользоваться SVN, читает лекцию, лично делает чекин/чекаут и следит чтоб компилили именно его Etable.h. Итог - Система под QNX стыкуется с системой под Linux, система под Windows не понимает пакеты от QNX.
6. Windows-Начальник запускает свой Windows имитатор на основе Etable.h, эти пакеты ловит другая Windows система, но не ловит системы под Linux и QNX.
7. Обнаруживаю, что пакеты на пару байт отличается по длине, меняю длину, проверяем - система под Windows начала принимать пакеты, под Linux перестала.
8. Никакие ухищрения с упаковкой структуры не помогали, сделать ifdef под каждую операционку Начальник не позволял (очень важно чтобы все компилили один и тот же код внутри {}, а если нет - то мы не програмисты). В итоге брали из SVN этот Etable.h, но компилили проект со своим, благо Watcom под винду не было.

Насколько я помню дело было sizeof(ххх), только ххх ничего не содержал в себе. И QNX с Linux вставляли в структуру 0, а Windows выбрасывал параметр из структуры и всё сдвигалось. Три отдела потеряли на это около двух недель рабочего времени.

[des00]

А вот пример про SVN в руках у дурака:

Все могу понять, но вот только причем здесь системы контроля версий, за исключением места где лежал файл?