Это как же так? Т.е. есть файлы my_function1.c, my_function2.c и т.д.? Как же вы их в исходники включаете. Ручками? А как это сделать мышкой?


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

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

ПС Блин, да неинтересен мне этот холивар, и обсуждать его здесь не вижу смысла. Подскажите по сути вопроса.

Странная логика. Отзеркалим: если вы тут, то вас что-то беспокоит. Но что?

Я работаю под виндой под не особо продвинутыми IDE и мне не нравится TotalCommander, предпочитаю Far. У всех разные предпочтения, и никто не заставляет менять методику разработки без необходимости, чего и вам советую.

Все умеют работать с наличными деньгами. Не все знают, что зарплату могут давать только через карточку.
Когда ее дают только через карточку, все "неумеки" осваивают за время до следующей зарплаты.
так и SVN.
Когда новый проект к нему принесут не на дискете, а только указав путь в SVN --освоится к следующему авансу. Там нет ничего сложнее, чем работа с зарплатной карточкой.

Я ищу реальные способы повышения производительносте, а не плацебо в виде Version Control System.
Поэтому не думаю что это "странный холивар".

Пока все аргументы сводятся "а мне так нравится", либо "групповую работу без Version Control System организовать нельзя"
Второй аргумент сильнее, но я бы нашел способы изолировать программистов друг от друга чтобы им не приходилось заниматься тесно связанными между собой исходниками.
И думаю TC как раз в том контексте и находится.



К кому принесут?
Все забывают о контексте, и только о своем наболевшем.
Речь идет хозяина проекта перевести на SVN, только потому что какому-то супервизору не нравится структура, состав его (хозяина) директорий!

Вот от этого и я бы не отказался. Придет время, найду и освою.


Выделяю нужные файлы, добавляю в Target. Писал же уже. Keil IDE. Это редкая процедура, это же не коммитить по 3 раза на дню.

Ну вот, видите? Видимо, у Вас нет проблем с версиями, но есть другие проблемы. В таком случае советую начать с требований. Т.е. от печки. Если освоите одну из систем контроля требований, то сразу снизится количество вопросов "зачем нужна VCS". Там просто технически весь подобный софт (нормальный, ессно) завязан друг на друга и тесно интегрирован друг с другом. Просто чаще будете сталкиваться с VCS. Или можно еще с багтрекинга начать (если нету еще) - это тем, кто чаще находится в "пищевой цепочке" дальше от начала проектирования. Там тоже тесная связь с версиями.

Т.е. зайти можно с разных сторон, главное, чтобы было желание поднять производительность. А в том, что это инструмент именно для этих целей, сомневаться не приходится.

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

Рекламируйте SVN как систему архивирования исходников с полезными дополнительными удобствами, как то:
- архивировать можно сколь угодно часто, место на диске расходуется весьма экономно, удобство которое не знакомый с SVN человек может оценить сразу
- номера версий само увеличивает
- можно сохранять прямо из IDE (если умеет)
- можно добавлять короткий комментарий
- удобно просматривать что и когда меняли
ну и т.д.

Непонятные народным массам слова коммит и чекаут временно заменить на сохранение и извлечение.
А там привыкнут.

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

Чем еще обманывать будете?

Правильно ли я понял, что вы при внесении изменения в файл my_fileN.c всякий рвз переименовываете его в my_fileN+1.c, ручками удаляете файл my_fileN.c из проекта Keil, и добавляете туда файл my_fileN.c?
А потом ищете в Тотал командере эти два файла и сравниваете их содержимое?
Тогда вам действительно не нужна система контроля версий.

2 All. По-моему, мы наблюдаем здесь откровенный троллинг со стороны пары модераторов и ViKo. Советую поберечь бисер.

Это все не то. Рекламировать и обманывать не эффективно. Эффективно только возникновение внутренней убежденности.
Вот еще один способ (уже третий, кстати, требую себе конфетку! )
Берете самого упертого и резко повышаете ему полномочия. Если чувствуете, что прогресс будет, то сразу и зарплату. Про ответственность молчите, ибо это и так понятно, что она тоже увеличивается.
Ну и ставите его тем самым супервизором. Пусть теперь он чего-то там хочет, бегает и приводит в порядок. Работу делите между остальными.
Он 100% начнет выдумывать доморощенные схемы и системы. В этот момент ему надо качественно (прям по методу Штирлица) подсунуть идею о стандартных средствах. Большинству инженеров нравятся стандарты. Лично я этот способ опробовал (в меру своих полномочий, понятно), и скажу, что эффективность его где-то процентов 70. Неплохо имхо.

И он прав. Это и есть реальная жизнь. Использую SVN года 3-4, большое удобство (хотя мне далеко за 50). НО! SVN поддерживается нашими системщиками и работает плохо - задержки, потеря файлов. Вижу только один способ - приказ с административными обоснованиями, а не удобством (удобства принимаются только после практического использования) , что:
- персональный комп может полететь и бэкап не всегда спасает
- программист может заболеть - умереть
- программист получает зарплату и его продукты принадлежат компании, а не ему
- созданные продукты могут использовать другие люди в компании
- всегда есть простой способ создания веток/вариантов изделия/программ (без SVN это сложнее)
- все созданные продукты (программы, документы, драйвера и пр.) и не только программы для конечного изделия/проекта должны храниться в одном месте (а не на разных персоналках работников).

Итак - только административный путь, потом привыкнут.

Нет, не только. Лично я имею практический опыт внедрения системы с нуля при прямом противодействии начальства. Это было вначале. А потом народ уже сам начал объяснять начальству что к чему, в результате для репозитория был даже куплен специальный сервер. И так на двух работах.

По сути весь вопрос топика сводится к необходимости осознания развития. Если его, осознания, нет, то это не страшно. Но и развития не будет. Обычное дело, в общем-то.

Ну так поделитесь своей success story.
Сколько строк кода было в проекте.
Для какой платформы.
Сколько человек трудилось и за какое время сделали.
Как часто делаете апгрейды у клиентов и с какой частотой ловите ошибки.

Тогда хотя бы можно будет как-то помериться.

Правильно. Но не на каждое изменение, а только при кардинальных. Когда и прежняя версия рабочая, и ее желаю оставить на всякий случай, для изучения и т.п.
Называю так: xxx_vnn.c В заголовке файла описываю, что же там особенное такое.
И сравнивать их мне нужно совсем уж в редких случаях. Вот когда с напарником сливались (в экстазе) посредством СКВ, и ловили непонятные глюки, вот тогда запускал сттарый добрый TC.
А для мелких изменений есть
#if xxx
...
#endif

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

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