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



Сообщение отредактировал bbb - Jan 31 2016, 20:56

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

Вы про что?

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

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

О том и речь.

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

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


До сих пор помню, как мне дали две версии написанного другом программистом софта.

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

В конце концов было выяснено, что он просто поменял значение константы и изменил код одной функции.
И изначальный объем отличий в более чем 6000 строк кода я свел в 12 строкам.

И на это я потратил две недели. Потому что программа была из серии "Mission Critical" и нужно было на все 140% быть уверенным, что я правильно понял то, что было изменено.

Так я понял насколько несовершенны ещё средства сравнения исходников и форма отчета об отличиях в версиях

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

Да проще тогда повеситься сразу

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

-----

#########################

------
К несчастью таких программистов 99%.
И разбираться в репозитории что же они наваяли - это ацкий ад
#########################

Сообщение отредактировал bbb - Feb 1 2016, 18:00

ИИ пока не создали. Так что - да. Любой инструмент, в том числе и CVS, лишь облегчает труд разработчика, а не заменяет самого разработчика.

Миллионы мух не могут ошибаться?
Мыши плакали, кололись - но продолжали есть кактус?
Вы считаете что функционал современных систем контроля версий иделально удобным для работы?
А я считаю как и AlexandrY, что пока что: "Контроль версий это механизм делающий что угодно, но только не контроль версий в истинном смысле понятия <контроль>".
И повторю что говорил:
1) системы контроля сейчас ещё пока не развиты.
Они не имеют визуализаторов отличий, которые могли бы сравнивать семантику/логику работы версий программы.
2) А пока что системы контроля версий просто напоминают бэкапы, в которых программист должен вручную обеспечивать атомарность изменений версий.
3) нужно чтобы система контроля версий сказала мне в одном-двух предложениях что изменилось. Чтобы я мог понять это за 1-2 секунды просто бросив взгляд на результаты сравнения. А не чтобы я тратил часы, дни и недели пытаясь разобраться в испещренном красным цветом искходнике: "что же он хотел-то когда правил исходник"



Вам никогда не приходилось заниматься "причесыванием" кода? (т.е. "рефакторингом" если сказать по научному) Когда исходник радикально меняется внешне, при то что его логика и смысл почти не меняется


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

Тут опять все зависит от "человеческого фактора". Насколько квалифицирован программист. Насколько дисциплинирован и добросовестен.

А любая зависимость от "человеческого фактора" "не айс" в разработке

Сообщение отредактировал bbb - Feb 1 2016, 18:13