Ну уж если Алтиум.
у мене несколько таких 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%.


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


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

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