[ViKo 1]

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

Теперь, как обычно, работаю одиночно. Системой контроля версий не пользуюсь. Добавляю номер версии в название файла. Всегда могу посмотреть предыдущий вариант. Нужный для проекта комплект файлов задаю в определенном Target для Keil. Так же одним махом могу выбрать другой Target, и тут же скомпилировать.

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

[ViKo 1]

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

Теперь, как обычно, работаю одиночно. Системой контроля версий не пользуюсь. Добавляю номер версии в название файла. Всегда могу посмотреть предыдущий вариант. Нужный для проекта комплект файлов задаю в определенном Target для Keil. Так же одним махом могу выбрать другой Target, и тут же скомпилировать.

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

[AlexandrY 3]

Вкратце - она дает возможность отследить историю каждого файла: когда и что менялось, зачем, и кем.

 

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

 

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

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

 

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

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

 

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

Так чтобы изменений было столько что неохото было бы за ними следить.

 

При наличии торчащего в интернет сервера позволяет не таскать исходники на флешке/внешнем диске.

 

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

Даже лучше весь имидж среды разработки в виде VirtualBox сохранить.

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

 

 

[syoma 1]

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

 

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

 

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

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

 

[Сергей Борщ 119]

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

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

Я насколько вижу,

Продолжайте наблюдение. Я пользуюсь давно, мне он очень помогает.

[Rst7 5]

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

[syoma 1]

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

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

[vitan 2]

Вводить в тему следует на живом примере и без жёсткого напора.

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

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

 

Если отсутствует понимание, что проект должен вестись в русле определённых и единых правил, то объяснять будет бесполезно. Будет только отторжение.

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

При отсутствии понимания я только за жесткий вариант. Ставится задача, не выполнили - сами виноваты. Искусственный Естественный отбор... :)

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

 

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

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

[Rst7 5]

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

 

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

[vitan 2]

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

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

[ViKo 1]

Не убедили. По крайней мере для одиночного разработчика. Зачем мне связываться с лишней сущностью, если могу обходиться без нее? Что я не смогу сделать (или будет труднее сделать) без системы контроля версий?

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

[Quasar 18]

Не убедили. По крайней мере для одиночного разработчика. Зачем мне связываться с лишней сущностью, если могу обходиться без нее? Что я не смогу сделать (или будет труднее сделать) без системы контроля версий?

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

 

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

 

[spf 0]

Зачем мне связываться с лишней сущностью, если могу обходиться без нее?

 

Это мне напоминает обсуждение других инструментариев для ПК, например "слепой печати".

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

"я не секретарша, чтобы печатать вслепую"

"я не архивариус, чтобы вести историю проекта"

 

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

 

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

 

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

 

PS:

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

 

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

[vitan 2]

Не убедили. По крайней мере для одиночного разработчика.

Я ж говорю, с этим сложнее. Видимо, просто, для Вас порог еще не достигнут.

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

[AlexandrY 3]

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

 

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

Старые версии никогда практически не нужны. Нужды в SVN соответственно нет.

 

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

 

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

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

 

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

 

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

 

 

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

 

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

Надо иметь всегда с собой свой компьютер.

SVN получается годен только для чего то мелкого или частного.

 

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

 

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

 

 

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

 

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