Ну вот, видите? Видимо, у Вас нет проблем с версиями, но есть другие проблемы. В таком случае советую начать с требований. Т.е. от печки. Если освоите одну из систем контроля требований, то сразу снизится количество вопросов "зачем нужна 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

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

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

Да никак не затрудняет. Даже проще, когда о переименовании помнит система, а не я. Хотя я редко переименовываю файлы уже в процессе разработки, не вижу смысла.

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


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

Какая система?
А если некоторые файлы проекта генерируются? И под разными названиями.
Ваша 'система' тоже об этом помнит вместо вас?




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

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

похоже, стоит отметить успешное начало осеннего обострения =)

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


А завтра "окажется", что они вообще не связаны с работой мозга, а связаны c <подставьте любую фразу>. И что? Зато я точно знаю, что если я буду изобретать велосипед, то мне придется загрузить мозг расчетами и моделями велосипеда, при этом я столь же четко знаю, что в итоге я не получу ничего, кроме велосипеда. А в магазине он стоит уже готовый. Поэтому логично представить эту информацию ненужной, не так ли?

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

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

Я поклонник Брукса знаете ли - Серебряной пули нет
Контроль версий это можно сказать ненужная сложность по Бруксу.
А также поклонник 1-го принципа Agile: люди и взаимодействие важнее процессов и инструментов.

не...е им так нужно, они так привыкли и возраст не позволяет ну и тд. Россия на находится в ж.. а там где её и положено по географии.
AlexandrY неушто вы не пользуете базар с ssh..., для html, xml и тд. Если понимаете о чём я.

Вообще-то я каких только контролей версий не ставил себе, многое ведь не скачаешь без этих приблуд.
Но пользы от них никакой не увидел.
Но дайте же мне наконец хоть одну success story из embedded по поводу влияния контроля версий на производительность хоть чего-то!

Вообще-то профессионала в 50 лет называть чайником - плохой тон, тем более что SVN - изобретение "эффективных управляющих" в ИТ-области.

Да что Вы говорите. И изобретение поля "версия файла" в ФС VAX VMS уже где-то лет 40 назад - тоже привет от "эффективных"?

Для тех, кто в танке - версифицирование - не вчерашнее изобретение, и даже не позавчерашнее. Что такое "лист регистрации изменений" знаете? И зачем он нужен?

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

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

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

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

жестоко однако


полностью согласен потому, что сам так делаю


но без подержки руководства ничего не выйдет

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



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

Ну уж если Алтиум.
у мене несколько таких SVN. Не моих. Чужих. Где я маленькая шестеренка.
Люди складывают в проекта папки с кодом, с программами, с описаниями, с механикой и черте чем еще. + все старые ревизии, которые дошли до "железа"
Там "Altium с библиотеками тоже гигабайты" выглядит мелкой сошкой на фоне хранимых объемов.
Если скачивать все--по первому разу (что в общем не требуется, для пользователя достаточно только нужные ему).

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

"как корабль назовёте, так он и поплывёт", в топике "тупой" - лишнее.

Банальный тролинг прогрессирует.

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

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

Про административно командный метод. Может, вам везет, но я не встречал руководителей, хотя были разные, хорошие тоже попадались, которые по своей воле решились бы что-то изменить. "Работает, и ладно". Они пока не потонут в накопившемся хламе прошлого, будут за него цепляться. А так, да, в идеале хорошо бы внедрить систему сквозного проектирования, перекидываться электронными записками, архивировать на сервере, контролировать версии и т.п. Лучшее, что я могу сделать - забить на всё, делать по-своему, рассчитывать только на себя и свои компьютеры. Лично мне, как боевой единице, части проектов сливать не нужно, дерево версий демонстрировать некому, по-большому счету, что и как будет работать, я сам определяю, как и где и в каком виде хранить.

Начинал с SVN, сейчас переполз на Меркуриал. Поддерживаю порядка 5 проектов + участвую в разработке 5 проектов. Над проектом работает команда ~3 человека. У меня 3 рабочих места. Без системы контроля версий голова давно бы уже опухла.

ЗЫ. Когда работал один тоже использовал систему контроля версий. При экспериментах в реализациях было порядка 3-4 веток, по окончании экспериментов нужные вещи мерджились в основную ветку, при этом всегда можно было вернуться к любому состоянию проекта.

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

Согласен, для мозга можно найти гораздо более приятные занятия.


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


Ну обычно его вспоминают, когда видят попытки по-своему решить задачу, которая уже решена общепринятым способом.


Можно так сказать. Только верно ли это утверждение? И где доказательство?


Вы, видимо, не до конца его понимаете. Суть не в том, что можно пренебрегать процессами и инструментами, а в том, что без людей и их взаимодействия не будет развития. Процессы и инструменты отражают ситуацию в статике, а люди (взаимодействующие) являются движущей силой для развития. Т.е. люди должны не отрицать процессы и инструменты, а должны отталкиваться от них в поисках лучшего. Но если они скажут, что видят прогресс в отказе от инструментов и процессов, то они будут неправы.
Да, они могут отказаться от чего-то одного, но взамен должны будут _обоснованно_ предложить другое. То, что по их мнению, будет лучше прежнего.
Ну и что Вы предлагаете? Помнить контекст в голове и сравнивать все тотал коммандером? Обоснуйте тогда, докажите, что это лучше! Что-то мне подсказывает, что тяжеловато Вам придется...



Вы даже не представляете, сколько раз я слышал подобные фразы!

От меня ничего не зависит. Я винтик. Зачем всё это? Я прекрасно разбираюсь внутри себя самостоятельно. Мои результаты всегда качественны. Улучшать нечего, придуманная мной система организации моего же труда почти совершенна. Да, хотелось бы большего. Хотелось бы использовать компьютер не только в качестве пишущей машинки. Но как только я что-то начинаю, все упирается в соседа, который такой же винтик, как и я. Ради каких-то абстрактных целей я не буду рушить с таким трудом созданную мной внутреннюю организацию. Неизвестно, чем еще все это кончится, скорее всего, ничем, только время потратим, это ж Россия!

Продолжать можно долго. Дело просто в желании, ничего более.
Кто не хочет - ищет причину, кто хочет - ищет путь.

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

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

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


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

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

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

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


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

Именно. Только не забывайте, что без писательства результата они не достигнут никогда, а вот, если займутся им, то - да, результат будет.
На вопрос "когда будет" ответ такой. Заменяете костюм на самолет, а двух швей на авиаконцерн. Самолет появится в строго прогнозируемые сроки. А вот без писательства будут, как ни забавно, только разговоры.

А что за код вы пишите (С-и, С++, asm ..., под линукс, под Win ...) и какого объема? Сколько файлов в вашем проекте?
И что называете проектом? Результатом вашего проекта является что: программа, плата, устройство, система..?

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

Объясню.
Ветки это просто немного другой код. Код жалеть нельзя. Это непосредственно следует из метафоры Брукса о мусорном ведре из книги "Мифический человеко-месяц"
Главное проект, архитектура.

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

Т.е. мне интересны психологические основы такого поведения.

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

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

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


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

Работаю в сфере беспроводной связи и вычислительных устройств.
Проект : разработка конечного устройства (софт, железо, интеграция) или разработка reuseble IP core. Язык разработки матлаб/Verilog/SystemVerilg/VHDL/embedded C(C+)/PC C(C++). Функциональные схемы : OpenOffice Draw, платы PCAD/Altinum. Корпуса и сборочники уже в Лоцмане.

В проектах 300-500 файлов, в среднем в файле от 200-1000 строк. Работает в команде системщик + embedded/PC программист + несколько HDL дизайнеров разных уровней.


Например обкатка разных алгоритмов обработки сигнала, обкатка реализаций по соотношению ресурс/производительность.

Срез (tag) это тоже ветка. Релиз софта выкатывается именно из среза, с конкретным номером. При поддержке проекта и поиске багов, берется именно то состояние проекта которое было отправлено клиенту. И повторяется ситуация с которой столкнулся клиент для изучения

Предыдущие посты меня не убедили в необходимости SVN в жизни эмбаддера.
Обязательно сохраняю заработавший код в отдельный архив и меняю ревизию. После каждой мысли перенесённой в код - нажимаю сохранение.

Был у меня такой опыт: писали вдвоём одну систему под QNX. Часть писал он, часть я. Один и тот же файл редактировать не было необходимости. Переодически обменивались работающими файлами. Система была создана и работала.

А был другой: пришёл програмист, создал отдел и сел там начальником. Купил сервер для SVN. Нанял 10 человек. Купил пачку лицензионной винды и вижуал си. Поставил Доксиген. Взял бетатестера. Найденые баги исправлялись только если они были зарегестрированы на сервере через веб интерфейс. И я там был. Добавлял ему из своих архивов в SVN коды. Разработка системы не была завершена.

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

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

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

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

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

Cреди людей, родившихся в 1839 г. и питавшихся впоследствии огурцами, смертность равна 100%.


Я все свои проекты делаю в одно лицо. И система контроля версий мне все равно очень помогает.


Мда. "Давайте спорить о вкусе устриц и кокосовых орехов с теми кто их ел".

Чем?
"Устриц" ел. Не вкусил. И сейчас это блюдо стоит перед носом (на компьютере). Иконки значками разнообразит.

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



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

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

Дядьку-то брали не чтоб он отдел создал, а чтоб созданный фирмой продукт был продан покупателю и дал прибыль.



Вот! Вы делаете проекты, они работают и продаются. И для того чтоб выполнять вашу работу вам нужна система контроля версий. А теперь представьте, что вам начиная со следующего проекта новый владелец запрещает пользоваться системой контроля версий. Удобно вам будет?

Я уже описывал в этой ветке.

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


Corvus, 5+

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

А.. это ваша нетленка про SVN на сайте embedders

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

И это то все надо сказать должно делаться в том самом печально известном Windows Explorer
Т.е. "Мыши плакали, кололись, но продолжали грызть кактус".






Ну прямо, "не ел"
Сергей не хотите же вы сказать, что мне поставить утилитку всю функциональность которой можно описать на 10 листах (TortoiseSVN) составляет какую-то проблему?
Проблема это вот те перлы перечисленные выше.

Ничего я не пытаюсь, это вы домысливаете. Я высказался, что меня TortoiseHg напрягла, а доводы апологетов не убедили.

Кстати, упомянутую выше статью я тоже читал. Давно, поэтому ничего не помню. Она дала повод задуматься, что ето такое.

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



Судя по всему вы пробовали использовать меркуриал. Эта система требует иного подхода к работе с репозиторием чем тот же SVN, я въезжал где то неделю в него.

Чужой старый код можно скомпилить только на томже компиляторе. И, возможно, при организации как у 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 выбрасывал параметр из структуры и всё сдвигалось. Три отдела потеряли на это около двух недель рабочего времени.

Недолго осталось до появления всероссийской ОС (на основе Linux). Все остальные ОС будут запрещены.

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

Проясните мне, чайнику 50+, тупой вопрос. Пишете вы программу, и вдруг на версии 2048 вас осенило, что в версии 2000 некий фрагмент был сделан лучше (правильнее). Но и в 2048-й сделано, естественно, много нужного.
Я мгновенно открываю старый файл, поиском или сравнением нахожу нужные места, копирую в файл с последней версией, и продолжаю работу.
Ваши действия, меркурианцы, тортильцы, субверсионцы - ...?