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

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

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

А такое объяснение как тут тоже не понимают? ---> https://ru.wikipedia.org/wiki/TortoiseSVN; https://ru.wikipedia.org/wiki/Система_управления_версиями

А попробуйте объяснить здесь.
Я, например, никогда не понимал зачем нужен SVN. И храню версии свих файлов в той же папке.

заставить пользоваться определенным механизмом на работе можно только административными методами.
пока нет необходимости в использовании определенного механизма (в вашем случае SVN) для получения заветных $$$ - финансово незаинтересованные работники будут если не бастовать, то итальянить.
как бы вы не старались "научить" их, если нет мотивации - не будет результата.

..присоединяюсь.
з.ы.
википедию прочитал, все сложно.

раз пошла такая пьянка, то мое мнение - TortoiseSVN не нужен.
под винду лучше уж сразу TortoiseHG или TortoiseGit. И только для проектов состоящих в основном из текстовых файлов.
там хотя бы kdiff3 (из комплекта) в нормальном виде сразу показывает что поменялось.

Они бывают не только свои, но и общие


Так не читать, а пробовать надо. Там для начала только 2 команды отдать и забрать

Все очень просто. Допустим, их там Х человек. Начальник дает им задание написать ОДНУ программу. При этом каждый будет писать 1/Х кода (пропорции можно контролировать деньгами при желании). Для верности перед окончанием работы поменять парочку малозначащих требований. И все наладится. Народ сам поймет, что нужен контроль версий, сам будет бегать за консультациями и организует факультативный кружок.

..т.е. смысл только для рабочих групп? Единоличнику это жизнь за счет чего может упростить?

За счет освобождения мозга от ненужной информации. Лично я начинал именно как единоличник. В этом случае важно количество работы в единицу времени. То бишь мощность разработчика. Если она низкая, то ничего не надо. Если высокая, то без доп. средств не обойтись. При этом причины увеличения мощности не важно в чем: одного начальник заставляет, другому самому интересно, третьему кушать хочется и т.д.

т.е. только пробовать , иначе не понять?

Нет, ну почему? Я лично осознал необходимость _перед_ тем, как попробовал. Просто понял, что мощность снижается из-за повышения времени. Слава Богу, до снижения количества не дошло.

Вкратце - она дает возможность отследить историю каждого файла: когда и что менялось, зачем, и кем. А также откатиться на любое из зафиксированных состояний для одного, нескольких или всех файлов. Позволяет не разводить бардак из кучи архивов. Позволяет вести несколько альтернативных вариантов файла/папки/проекта и легко (одним движением/командой) сливать правки одного варианта в другой. При наличии торчащего в интернет сервера позволяет не таскать исходники на флешке/внешнем диске. Для групповой разработки есть еще дополнительные плюшки.

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

Вводить в тему следует на живом примере и без жёсткого напора.
Как вариант - создать совместно набор правил по работе с хранилищем, "как работать с хранилищем", затем довести это до "стандарта" во всём коллективе.

Все подобные вещи (системы ведения версий) в первую очередь являются инструментом дисциплинарного уровня, а все остальные плюсы - это уже сопутствующие довески.
Если отсутствует понимание, что проект должен вестись в русле определённых и единых правил, то объяснять будет бесполезно. Будет только отторжение.
Отторжение из-за внутреней дисциплины и привычек высокого уровня и в жёсткой форме, или же наоборот, из-за полного отсутствия понимания необходимости дисциплины при разработке.

Дока на сам SVN написана лучшим образом, читать её от корки до корки до понимания всех плюшек. :-)

Попользовался TortoiseHg, пока работал в паре. С горем пополам сливали файлы проекта, когда он заходил ко мне, колдовали... Приходилось иметь дополнительную папку с тем же проектом, в качестве хранилища. Побочные ответвления выглядели как никому (мне уж точно) не нужные аппендиксы. Если же искать различия в файлах, то мне (и ему показал) проще пользоваться Total Commander-ом, чем штатным средством. Вообще, с трудом представлялось, что там мы сливали, будет ли работать после этого.
Теперь, как обычно, работаю одиночно. Системой контроля версий не пользуюсь. Добавляю номер версии в название файла. Всегда могу посмотреть предыдущий вариант. Нужный для проекта комплект файлов задаю в определенном Target для Keil. Так же одним махом могу выбрать другой Target, и тут же скомпилировать.
В-общем, не проникся. И, да, подхожу под определение чайника из заголовка темы.

Попользовался TortoiseHg, пока работал в паре. С горем пополам сливали файлы проекта, когда он заходил ко мне, колдовали... Приходилось иметь дополнительную папку с тем же проектом, в качестве хранилища. Побочные ответвления выглядели как никому (мне уж точно) не нужные аппендиксы. Если же искать различия в файлах, то мне (и ему показал) проще пользоваться Total Commander-ом, чем штатным средством. Вообще, с трудом представлялось, что там мы сливали, будет ли работать после этого.
Теперь, как обычно, работаю одиночно. Системой контроля версий не пользуюсь. Добавляю номер версии в название файла. Всегда могу посмотреть предыдущий вариант. Нужный для проекта комплект файлов задаю в определенном Target для Keil. Так же одним махом могу выбрать другой Target, и тут же скомпилировать.
В-общем, не проникся. И, да, подхожу под определение чайника из заголовка темы.

А как SVN узнает "зачем"? Не пошла ли уже тут мифологизация?

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

Другая его функция - это слежка. Как только хотят начать следить за программистом его сразу заставляют использовать SVN.
Разобраться в его коде это не помогает, но зато отлично помогает цепляться к формальностям и типа внедрять 'дисциплину'.

Против SVN у меня выработалась привычка периодически полностью рефакторить код.
Так чтобы изменений было столько что неохото было бы за ними следить.



Нынче на облачные диски один архив поместить проще, чем SVN там будет скрипеть по каждому файлу пересылать мелкие фрагменты.
Даже лучше весь имидж среды разработки в виде VirtualBox сохранить.
Последние семинары по разработке в Линукс так и проходят.

Эй народ, помедленней, я записываю!

Задача пока не под коллектив, а для пары разработчиков, которые каждый ведет свой проект и шефа, который как-то должен понимать, как все это работает. Т.е. коллективных проектов нет пока.

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

Он предлагает вам написать об этом при фиксации. Хотите облегчить себе жизнь - пишите честно и подробно и потом вы сможете эту информацию прочитать. Не хотите - не пишите, тогда ни он ни вы через некоторое время не будете знать "зачем". За вас он ничего сам не придумает.
Продолжайте наблюдение. Я пользуюсь давно, мне он очень помогает.

По собственному опыту за десяток лет использования системы контроля версий (конкретно SVN), получилось примерно так:

- Откатывался на несколько предыдущих ревизий ну раза три максимум. Хотя Revert (откат текущих изменений) использую довольно часто - пишешь, пишешь, понимаешь, что плодишь ересь, делаешь revert и начинаешь плодить новую ересь

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

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

- Совершенно спокоен за резервное копирование. Мало того, что репозиторий на сервере регулярно бэкапится, так еще и найдется несколько компьютеров, на которых есть локальные копии последних ревизий (после checkout'а). Так что даже если совсем форс-мажор, то самые свежие ревизии у меня найдутся.

- Взял в привычку складывать рядом с файлами-исходниками проекта всякие даташиты, небольшие утилитки, и коммитить их тоже. Зато потом организация рабочего места на любом компьютере при наличии интернета производится за полчаса - вытаскиваем SVN-клиента, идем в закрома, вытаскиваем необходимый компилятор, делаем checkout, весь джентльменский для продолжения работы над проектом уже есть.

- Пишу довольно развернутые комментарии при Commit'е. Не то, чтобы сильно часто приходилось искать, где я и что делал (ну может несколько раз), но зато вполне дисциплинирует, и я точно знаю, что если мне понадобится найти какую-то правку, то займет у меня это достаточно обозримое время. Ах да, еще очень желательно писать по чьей просьбе или требованию в проект внесены какие-то правки, например, в основном алгоритме. Позволяет, вдруг что, с железной уверенностью послать какого-нибудь искателя виноватых в маленькое эротическое путешествие.

- Ну и после всего вышеперечисленного, повышение душевного спокойствия - оно ж просто бесценно

Это все понятно, но вопрос все-таки не в целесообразности SVN и как лучше с ней работать, а как обучить людей с "ограниченными способностями" базовым навыкам, чтобы у них не случился вынос головного мозга? Википедия - сложно. Описание Subversion получше, но про Гарри и Салли они не поймут. Может есть еще что-то проще?

Вариант нормальный, но сильно затянут во времени, можно не дождаться результата. Проверено.


При отсутствии понимания я только за жесткий вариант. Ставится задача, не выполнили - сами виноваты. Искусственный Естественный отбор...
Если есть внутренняя дисциплина, то должна быть и коллективная дисциплина. Если у людей со внутренней дисциплиной есть отторжение, то они, очевидно, способны сформулировать причины и\или предложить другие варианты решения вопроса (другую VCS, например). Это как раз не проблема.


Дык ну а какая разница? Даже один человек - частный случай коллектива. Особенно, если ведутся длительные проекты, если много вариантов, если самих проектов много, короче, если относительно высока та самая "мощность". А два человека - уже вполне себе коллектив. Просто, если людей больше одного, то самый простой путь - разделить между ними работу. Для одиночки так не получится, придется либо увеличивать количество работы, либо снижать время, других параметров в формуле мощности нет.

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

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

Не убедили. По крайней мере для одиночного разработчика. Зачем мне связываться с лишней сущностью, если могу обходиться без нее? Что я не смогу сделать (или будет труднее сделать) без системы контроля версий?
У меня в начала каждого исходника описаны все модификации программы, в хронологическом порядке. Комментариев у меня до... много. Каждая функция предварительно описывается. Все оформлено под Doxygen. При желании (иногда и по требованию заказчика) могу выдать документацию на ПО, во всяком случае, чтобы отвязались, хватит за глаза. Если нужно ответвление, создам отдельный Target, как говорил, с новой версией.

Ну например, периодически наблюдаю такое у некоторых коллег. Пишется код на двух машинах, ноутбук и десктоп. Бац, нашли ошибку (баг №1), разработчик на ноутбуке её исправляет и прошивает изделия, вроде бы проблема исправлена, забыли. Код заархивировал и заботливо слили на флешку с именем my_project (612098423435225).rar. Через какое-то время обнаруживается новый баг (баг №2), ноутбук дома, баг начинают исправлять уже на десктопе, позабыв разархивировать туда свой my_project (612098423435225).rar. "Ура, баг номер 2 исправили! Хм, странно, а почему опять проявляется баг номер 1? И что я там правил, кто мне напомнит?"

Это мне напоминает обсуждение других инструментариев для ПК, например "слепой печати".
Когда не владеющий подобными навыками упорно сопротивляется и с кучей "доводов" стоит на том, что это не нужно и ничего нового и хорошего не добавляет.
"я не секретарша, чтобы печатать вслепую"
"я не архивариус, чтобы вести историю проекта"

Да, можно обходиться вообще без новых технологий (с очевидными и логичными плюсами), печатать одним пальцем и плодить кучу архивов с "мудрыми" правилами их формирования и учёта.

Выбор есть у каждого.

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

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

Использую VCS (cvs/svn/git) больше 10 лет и печатаю вслепую :-)

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

for Quasar
Для устранения подобного я элементарно синхронизирую папки рабочего компьютера и флэшки в Total Commander, а потом флэшки и домашнего компьютера. Еще можно и в DropBox закинуть, но им, практически, не пользуюсь.
С VCS можно тоже нагородить всякого, скачи потом по бранчам...


Total Commander, сравнить файлы по содержимому пробовали?

В таких случаях всегда молча высылаю последнюю версию firmware клиентам. У меня клиенты имеют всегда самый новый софт и единообразную документацию.
Старые версии никогда практически не нужны. Нужды в SVN соответственно нет.



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



При современном качестве носителей две копии держать рисковано. Держу для важной информации всегда три копии в разных физических местах.




Современный сложный проект встраиваемой системы на любом рабочем столе не открыть. Там одна модель дивайса в SolidWorks может под гигабайт занимать, Altium с библиотеками тоже гигабайты.
Надо иметь всегда с собой свой компьютер.
SVN получается годен только для чего то мелкого или частного.



В большинстве случаев нельзя в паре строчек описать всю суть обновлений. Поэтому короткие комментарии чаще всего вводят в заблуждение.




Душевное спокойствие это когда твоя любимая работа всегда с собой.

глюк

Я не пользуюсь Total Commander, зачем мне еще одна сущность? Я знаю только rar и больше ни чего знать не хочу

Не верю. Все спецсимволы знаете? | ~ • § и т.п.
Можно быстро набирать текст, но сильно ли сказывается это на общей производительности программирования?


Мне вам посочувствовать, что ли?

А я набираю одну команду в командной строке. И она работет даже если я уже внес новые изменения.
А сколько времени вам нужно, чтобы разобраться, какие именно файлы из проекта надо сравнивать (т.е. какие изменялись за это время)? Мне достаточно набрать одну команду или сделать три щелчка мышкой. А сколько вам надо времени, чтобы найти архив, в котором было последнее изменение файла xxx.c? Мне достаточно набрать одну команду или сделать три щелчка мышкой. На этом заканчиваю. Раз вы считаете, что вам это не нужно - значит вам это действительно не нужно. А я освободившее время использую на что-нибудь полезное.

По номеру версии в имени файла вижу.
Набирать вообще не надо, только мышой кнопки нажимать.
Мне, особо, и не нужно возвращаться к древним вариантам. Последние - самые лучшие.
Одной командой вы не сможете сделать тройное архивирование проекта, как у меня с флэшкой и двумя компами. А то и четверное, если с DropBox. Значит, для хранения используете еще что-то.

Да, подтверждаю, средств Total Commander хватает выше крыши на все операции сравнения и синхронизации.
Я бы даже сказал, что Total Commander это лучший из всех SVN-ов
А файловая система лучшая из всех структур для хранения данных.

До боли знакомая песня.

Что ж, рад за Вас. У Вас нагрузка низкая и жизнь прекрасна. Или Вам любая задача по плечу.

Обратите внимание, никто никого в этой теме _убеждать_ ни в чем не будет. Люди попросили _объяснить_, в чем могут быть плюсы. Если для Вас аргументы не убедительны, то это - только для Вас. Для объясняющих этих аргументов было уже достаточно, они _уже_ работают с VCS. Вывод: все относительно, у всех разные "пороги срабатывания", и для Вас этот момент еще не настал.

Странный холивар: есть люди, которым удобно и при одиночной работе пользоваться VCS, есть те, которые и без нее обходятся отлично. Если же работа в команде, то правила должны быть едины и пусть человек сам учится, если хочет быть в команде.
Лично мне прежде SVN, а теперь и Fossil удобен именно возможностью откатиться на шаг назад, простотой синхронизации между рабочими местами( ну не люблю я ноуты), возможностью веток для странных хотелок заказчика и меток для однозначного поиска старого. Иногда надо посмотреть, что изменилось со времени Х и не поэтому ли полезли новые глюки, особенно при мелкой дороботке старых проектов. Если и так хорошо - зачем заставлять себя или соседа?
Я, например, никак не могу понять для себя пользу смартфонов: мне важнее 2..3 недели без подзаряда. А кто-то без них не может и готов по 2 раза в день заряжать. Важно показать возможности и пусть человек сам решает, надо или нет.

Это можно отнести к уровню комфорта, как и топиковую тему. Но для каждого влияние этого на "производительность" будет разной, т.к. нет универсального её мерила.
Аналогия.
Можно сидеть на табуретке с напряжением спины и шеи, а можно в кресле расслабившись. Это скажется на производительности?
Обязательно, т.к. в напряжении при высоком темпе долго сложно продержаться, а в кресле - легко и сколько угодно.

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

+1.
Я могу еще добавить, что у многих упомянутый "порог срабатывания" превышен значительно сильнее, и многим недостаточно уже и ее (VCS). Помимо VCS народ использует и багтрекеры, и системы контроля требований, и т.д. и т.п. Вот лично я, например, вообще почти ничего не программирую, но активно использую CVS для управления документацией (ЕСКД) и файлами проектов печатных плат, ПЛИС и т.д. При этом мне этого не достаточно, и я еще дополнительно связываю все это с системой багтрекинга (это у меня абсолютный минимум). А еще хочется нормальную PDM, а лучше PLM... И требования тоже хочется... И вообще хочется максимум переложить на компьютер, чтобы мозг занимался собственно разработкой (творческой работой), а не рутиными вещами. Это чисто вопрос личного выбора каждого.

Я вам по секрету скажу: из первого второе не следует ну ни разу. Для чего нужны системы контроля версий, вы не знаете. Как они работают, вы не понимаете. Соответственно, вы ими никогда не пользовались. А раз всё так, то что вы делаете в этой теме? Потроллить зашли?

Странных холиваров не бывает.
Если вы тут, значит что-то вас в этом беспокоит.
Но вот что?

Я так несмело предположу, что некоторые работают под линуксом где нет Total Commander.
А некоторые всегда работали и работают с GCC и не в курсе проблем которые вызывает произвольные Version Control System в продвинутых IDE

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

Читаю этот и другие посты и вижу закономерность в ответах. Правда сейчас опять начнут меня "гвоздить" за ссылки на мои же статьи. Так вот, у меня есть статья "Квадрига..." и там написано по "мотивам" статей о зависимости производительности труда от количества работников.
И там сказано, что при увеличении числа работников производительность резко падает.
Теперь смотрите на переписку, которая ведется здесь. В том случае, когда человек работает сам по себе, без "подельщиков", ему никакие средства повышения производительности труда не нужны. Как только в проекте оказывается 3-5 или более людей начинается неразбериха с версиями файлов. Я это запомнил крепко, т.к. однажды руководитель проекта продержал меня на работе в воскр. до 7 вечера и только после этого он опознал, что файл, который сделал другой разработчик, который в это время сидел дома у телевизора, и этот файл входил в мой проект, и этот файл был старой версии и не работал... А я этого понять не мог, поскольку в чужом файле ничего не понимал, не до того было.
Собственно мой ответ в том, что если работаете командой, то необходимо применять средства, защищающие работников от ошибок. И от применения старых версий файлов, которые сделали их сослуживцы. И таким образом, это не желание отдельно взятого человека - "хочу или не хочу"... А это дело всей команды. Либо "Мы все хотим зарабатывать здесь", либо ... И далее ищутся меры защиты от ошибок и повышения производительности труда. А будет ли это софт или выбранный человек - не так важно. Просто софт это сделает надежнее.
Так что вот. "Хотите работать в команде или нет"? - вот единственный вопрос, который требует ответа от Ваших " оставшимся в прошлом веке". Ну и от их начальника... После чего надо найти человека, мнению которого можно доверять и он должен сказать, какой именно софт для Вас подойдет...

Это как же так? Т.е. есть файлы 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 раза на дню.