Тогда наверное про SVN еще не знали?

Зачем заморачиваться с backup по idle, если бекапы репозитария настроены на сервере вместе со всеми другими вещами? Зачем мне изучать и настраивать еще один софт, притом на каждом рабочем месте, или если я снесу винду на компе?


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

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




SVN делали для проектов Open Sourse. А не для индивидуалов или производственных фирм.
Open Source это годами ковыряние в текстовых файлах и переливание из пустого в порожнее.
Такие виды деятельности как создание PCB, конструирование, исследования, испытания их никогда не волновали и не волнуют. SVN к ним никак не приспособлен.

Вы сейчас будете внедрять уже устаревшую VCS на фоне новых, распределенных VCS, вроде Git, Mercurial, Bazaar и т.д.
Рекомендую Mercurial.
Меркуриал позволяет все то, что SVN и Git, только удобнее и проще (чем Git, для которого написали аж целую книгу ProGit.).
Простота установки для пользователя - один установщик (TortoiseHG) - и стоит сама VCS и визуальный клиент. Для Git (под Windows ) такого не нашел. Одна сплошная боль.
По преимуществам распределенных VCS хипстеры накатали уже не одну статью, все преимущества там озвучены:
Сравнение Subversion и Mercurial (HG)
Переход на DVCS, Mercurial
Переезд с SVN на Mercurial: личный опыт

Ну и серия статей от одного довольно известного программиста:
Hg Init: Часть 1. Переобучение для пользователей Subversion

Все свои проекты держу на bitbucket.org. Очень удобно, не нужно ничего таскать на флешке.


0. Настройтесь на многократное повторение одного и того же.
1. Должна пойти команда от начальства - с этого дня начинаем жить по новому.
2. Все проекты начинаются в системе контроля версий.
3. Выделяется сервер для централизованного хранения проектов.
4. Минимум одна фиксация за 8 часов работы, например вечером.
5. Зафиксированная версия должна собираться. В редких случаях (масштабный рефакторинг) можно фиксировать несобирающийся проект. Лучше такие штуки пресекать. Проект должен собираться всегда, с самого начала.
6. Начальник контролирует, как часто делаются фиксации. Если реже раза в день - сначала мягко увещевает, затем карает все жестче.
7. Проверяется, правильно ли заведен проект. Проект выкачивается на другую машину и собирается. Если есть особенность сборки проекта - заводится документ, кладется по контроль версий в проект.
8. Старые проект по возможности, плавно (резко здесь нельзя) переводятся на контроль версий.
9. Завести базу знаний, например, на wiki движке. Там постепенно составлять FAQ по работе, успешные приемы, инструкции.
10. (Неплохо бы). Каждый проект ведется минимум 2-мя разработчиками. Достигается знание разработчиками смежных проектов. Тренируются навыки командной работы. Снижается риск потери одного из разработчиков (болезнь, увольнение). Снижается вероятность принятия диких решений, за счет инспекции кода другим разработчиком и принятия решений сообща.

Хорошая статья.
Только остался неясен момент как же все таки Git упрощает и ускоряет слияние. Что там упрощается.

А таскать по любому надо, и на на флешке, а на диске.

За советы спасибо. Но меня, как того человека, которого не привлек переход на контроль версий, не привлек переход на децентрализованую CVS. Tortoise тоже прекрасно отслеживает коммиты без апдейтов, и externals могут ссылаться на определенную ревизию. Все остальное для меня неактуально пока, а так как человек на хабре описал, так я гит вообще людям не обьясню. Так что пока хватит SVN.

Отличная статья. Спасибо. Хорошо показана ничтожность различий между двумя крайними точками в развитии VCS. Т.е. общая идея: "в новой это сделано удобней, чем в старой". Не более того.
Раньше мы что-то делали командой "dr pr", теперь же то же самое можно сделать, введя команду "pr dr". Насколько продумано! Разработчики потрудились на славу!!

Ну а то, что ниже 0-1-2-3.. - то замечу одно: Следование любым унифицированным процедурам снижает производительность работы. Как минимум в среднесрочной перспективе. Очевидно, что чем больше внимания уделяется процедурным вопросам, тем меньше его остается на основном направлении удара. И наверное не стоит превращатьVCS в систему управления проектами, контроля качества, порядка исполнения и т.п. Она для этого не предназначена. Т.е. конечно есть наиболее удобный с точки зрения VCS порядок работы, но удовлетворяет ли он основным требованиям проекта - большой вопрос.

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

Я, все же, попробую для новой версии firmware попользоваться TortoiseHg.
Читаю этот документ - http://bacher09.org/hgbook/ru/html/

А между тем... Google Go меняет систему контроля версий с Mercurial на Git

Чет какая-то новость из другого мира.
При чем тут электроника и embedded?

Давайте уже тогда все бредовые проекты google здесь пообсуждаем.

Плохой документ для начала. Он старый, 5-летней давности. Не вижу смысла запоминать консольные команды, смотреть их вывод и вообще читать о работе через консоль. Скорее нужно понять основные термины (commit, clone и т.д.) и работать через графическую оболочку HG Workbench и через контекстное меню.

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

Вот этих двух статей хватит чтобы покрыть большинство потребностей на первое время:
http://dreamhelg.ru/2009/02/tortoisehg/
http://lifeexample.ru/razrabotka-i-optimiz...-mercurial.html

Как лучше, вот так:


Или так:



Это наезд на Меркуриал

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

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

Так же может получиться и с HG/gt. Гит - мейнстрим, его используют огромное количество проектов. Ртуть - тормозной уродец на питоне. Подумайте, есть ли смысл вкладывать своё время в его изучение?

Мне, как одиночному писателю, не все ли равно, в какой Тортиле нажимать кнопки?

Опять мировые проблемы.
Вы что, Google? Или такие как Google? Или знаете что нибудь про их внутренние технологии?

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

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

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

У Гита есть существенный недостаток: при переносе/переименовании/клонировании файла(или хотя бы родительской папки) его клон не связывается с родителем и цепочка истории изменений прерывается и начинается с нуля. Я попробовал прочитать статью Линуса, почему он так сделал, но нисколько не проникся. Большие проекты Ртуть может и не очень тянет, но, подозреваю, большинству и не требуется поддерживать проекты масштаба ядра Линукса.
На всякий случай сделал тестовый репозитарий с 17000 коммитов с добавлением по новой строчке в один файл. Ртуть ведёт себя вполне пристойно(кстати, гораздо лучше SVN), а больше коммитов в моих проектах в обозримом будущем не ожидается. Конкретно, в Workbench, хвост истории открывается почти сразу, общий фильтр по истории с условием tagged() и одним тегом в истории перевычисляется около секунды, другие варианты фильтра 7 секунд, история файла(с 17000 дополнений по 50 байт) открывается примерно полсекунды.

HG, 3 разработчика, 4 ре ветки, активная часть разработки

Ну видно, что полмесяца проект шел ни шатко, ни валко.
Ветвей особо не наблюдается. Меньше одной ветви на разработчика. Они что, спят?
Не было сделано ни одного тега.
Хваленая способность Mercurial легко ветвить и мержить явно не используется. Зачем тогда он был выбран?


И вот что на этом этапе делает контроль версий кроме как выполняет функцию примитивного backup-а ?

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

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

Мы стараемся держать не более 5 ветвей, 1 на сборку, 1 основная и 2-3 отладка фич. ветки в бесконечность не уходят.

Гениально, так и буду теперь оценивать результат.

вы либо тролите либо издеваетесь и это вас совершенно не красит:
1. тег делается когда есть стабильный рабочий релиз, смысла делать тег на нерелизнутом проекте нет.
2. в отличии от SVN смысла делать тег в hg нет

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

Да, времена настали. Теперь любая ирония называется тролингом.
А иронизировал я потому, что ничего другого не остается когда на просьбу показать проект выкладывают малопонятный скриншот.
Если мне были бы нужны такие картинки я бы их на GitHube нашел бы достаточно.
Но GitHub очень мало касается embedded и электроники. Поэтому интереса не представляет.

Кстати о ветках.
Да именно ветки их огромное количество преподносят в книжках по Mercurial как его абсолютное достоинство.
Работаете вы может и складно и у вас все хорошо, но мощь TurtoseHG получается не используете.
Так мощь ли это на самом деле? Вот в чем вопрос.

Или вы хотите сказать что ветки разработчиков скрыты в их собственных локальных репозитариях?
Тогда зачем ветки в основном?

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

В рабочей копии создаётся полноценный клон всего репозитория и это правильно. Коммиты делаются только в этот клон, в удалённый репозиторий коммиты в принципе не делаются(это вам не SVN ), а делается PUSH, который можно выполнять параллельно редактированию рабочей копии. Чтобы коммиты выполнялись быстро, просто не надо добавлять в репозиторий всякий мусор.

Знаете, лучше взять Acronis True Image и не мучать диск и свою голову вопросом что есть мусор и чем отличается PUSH от COMMIT

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

Поэтому любые скрины которые вам будут показаны, будут априори не те и не то. ИМХО вы занимаетесь тем, что задаете вопросы, ответы на которые не хотите ни знать, ни осознавать. Это издевательство над собеседником. При всем уважении к вам, вести с вами конструктивный диалог на эту тему у меня уже нет желания.

Я с не меньшим уважением отношусь к Вам.
Просто не поняли друг друга.
Относитесь к этому легче.
Контроль версий в действительности не такая важная вещь в жизни разработчика как может показаться. Об этом я и хотел сказать.
Я работал в десятком фирм занимавшихся так или иначе встраиваемым софтом. Нигде при мне не применялся контроль версий!

Ну я надеюсь CAD'ы-то там применялись? Altium Designer там, Mentor, P-CAD, AutoCAD?

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

Месяц назад стал активно использовать Ртуть. Уже 25 фиксаций, 3 ветки (просто названия другие, а так как шло линейно, так и тянется). Однажды откатился назад, убедился, что работает, и снова переключился в голову. Приятно глянуть на комментарии к фиксациям, и показать, что не зря протирал штаны, если спросит кто (посмеет).

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

Во-во, жалкое подобие помидоров.

Я тоже с самого появления этой ветки в форуме тестирую использование SVN. Скоро месяц будет.

Поставил на 5-ть текущих проектов, чисто программных. Для аппаратных или исследовательских проектов вообще не увидел смысла.
От 40 до 70 коммитов в каждом.

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

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

Хуже, что все комменты распылены по разным проектам и нет единой картины потребления проектами времени. Потерян общий контроль за производительностью.

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

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

Потихоньку забрасываю этот SVN.

Сегодня помидорная программа понизила мне рейтинг. Наверное, за то, что обрывал помидоры. Вот и стимул появился - вернуться на прежний уровень.
Очень интересно взглянуть на статистику, в какое время производительнее работал, в какие дни недели.
Все, свистит "арбайтен!"

AlexandrY - ну так комменты писать никто ж не заставляет? Если не надо по проекту - то зачем на них тратить время? А по производительности - разве SVN предназначен для контроля производительности?

TortoiseHg не позволяет провести фиксацию (commit) без комментария. И это правильно (с). Иначе не вспомнишь, на каком этапе закоммитил. Если не нужен именно этот этап - зачем тратить время и байты на диске?

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

Я не за Александра отвечаю. Просто довожу информацию. И высказываю мнение. Контроль версий - не бэкап. Версия должна быть со смыслом.

там на автоматику по экшенам можно вешать внешнии скрипты, можно автоматом (есть штатные у него средства) - вставлять
метки. ну типа кто коммитил, дату-время...и т.д.. их там штук 10-20 разных типов.

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

Ой.. А как вы жили без контроля версий? Наверное очень простые проекты?
Ко мне начальник (лентяй) приходит и говорит "а надо бы добавить дабл клик к кнопочке".
Я лезу в svn, вижу в комментах что полгода назад это было и говорю ему.
Хочет - восстановим.




Ой.. В России каменный век. За последние 15 лет и почти столько же компаний ни одной, где не было контроля версий.
Если нет контроля версий, это любители, не профессионалы.

Вот это я и опровергаю. Нет ничего в ваших комментах.
В исходниках да, но в комментах SVN нет.

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



Так это ж натурный эксперимент. Понять, так сказать, психологию юзера SVN.

Задорновский шша-шный персонаж детектед.
В этом треде одна звезда из прибалтики, другая из РБ. Оба маргиналы и оба не способны работать в современных девелоперских коллективах.
Вопрос, причем тут Россия?
А вот в шша на свн остаются одни нищеброды.
Если чо я из киева и контора ведет проекты в аккуреве и разумеется все сказанное плод моего имха

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

P.S. уже исправил функцию

А что так невнятно про accurev , будто стесняетесь?

Давайте поговорим про accurev.

Хотя непонятно каким концом применить этот accurev в цикле разработки встраиваемых систем.

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

Вы что нибудь понимаете в Agile ?

Agile, Jira, Confluence, SVN

Да мы их на завтрак едим! Вместе со встраиваемыми системами!

Ops - сорри - это не относится к моей теме, так как работаю на две конторы - в одной -прогрессивной Agile, Jira, Confluence и SVN летают, а в другой - смотри первое сообщение.

Как нет? А куда все делось?
Ну вам виднее, че у меня есть, чего нет..




Это не важно, какая система. Какая есть в конторе, на той и работаем.
Главное, что бы она была.

Не хочу создавать новой темы, задам вопрос здесь знатокам контроля версий.
Хочу давать принудительно осмысленный номер версии, например, V3.0, чтобы одновременно менялась в исходниках (в шапке файла, в строковой переменной) и в системе TortoiseHg. Никак не возможно?

Я все делаю через #define в сурсе.
Чем это плохо?
В комментариях к commit отмечаю каждое изменение названия версии.
Потом искать легко.
Или вопрос об автоматическом изменении?
Такое тоже можно.
svnversion.exe работает через пень колоду. В смсыле в батч файле работает, а в нем же из по IAR нет.
Билд номер автоматически меняется

http://mercurial.selenic.com/wiki/VersioningWithMake
плюс, дать вменяемое имя релизной ветке перед сборкой

Думаю надо использовать механизм Hooks в движке Mercurial.
В обработчике pre-command Hook-а вызывать скрипт на Python-е который быстренько до формирования новой версии в Mercurial обновит шапки в файлах проекта или еще чего сделает полезного.
А скрипт надо написать самому.

C хуками есть нюанс.
Сформированный список файлов для комита нельзя изменить хуком.
Например, комичу main.c. Хуком обновляю текст в version.h.
main.c попадает в комит, а version.h нет.
Разбирался с этим вопросом пару лет назад, может уже что-то изменилось?

А в Teamcenter контроль версий поддерживается?



Хммм...
А это тогда что?
https://ru.m.wikipedia.org/wiki/Ос2000

Присоединяюсь к вопросу!
*****************
А вообще системы контроля сейчас ещё пока не развиты.
Они не имеют визуализаторов отличий, которые могли бы сравнивать семантику/логику работы версий программы.

К примеру, программист всего лишь изменил имя одной переменной. При этом ЛОГИКА ПРОГРАММЫ НИКАК НЕ ИЗМЕНИЛАСЬ. А арахис, beyound или встроенная сравнивалка сразу тысячу отличий в листинге мне покажут!!! Хотя, повторюсь, логика не менялась.

И теперь, чтобы понять, что же сделал программист, я должен просмотреть и пранализировать 1000 отличий с целью выяснить: а что же изменили и зачем. Потратить ЧАСЫ, чтобы понять, что ничего не изменилось в семантике/логике. Просто программист придумал более удачное имя для переменной. И все.

Хорошо бы если бы SVN умела бы представлять разницу/отличия в виде: "Глобальная переменная "А" была переименована в "X".

Но этого SVN делать не может.

Как и много чего другого, что было бы РЕАЛЬНО УДОБНО И ПОЛЕЗНО, не могут.

И потом.... При использовании SVN у некоторых в репозитории более 1000 версий накаплавается. Попробуй там разберись.. Так что ещё бабка надвое сказала: облегчает ли SVN работу или напротив усложняет её.

Если мозга нет - ничего не поможет

Вы про что?

Да ни про что. Не обращайте внимания.

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