[ViKo 1]

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

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

[A. Fig Lee 0]

Я все делаю через #define в сурсе.

Чем это плохо?

В комментариях к commit отмечаю каждое изменение названия версии.

Потом искать легко.

Или вопрос об автоматическом изменении?

Такое тоже можно.

svnversion.exe работает через пень колоду. В смсыле в батч файле работает, а в нем же из по IAR нет.

Билд номер автоматически меняется

[krux 8]

http://mercurial.selenic.com/wiki/VersioningWithMake

плюс, дать вменяемое имя релизной ветке перед сборкой

[AlexandrY 3]

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

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

 

Думаю надо использовать механизм Hooks в движке Mercurial.

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

А скрипт надо написать самому.

[JohnSilver 1]

C хуками есть нюанс.

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

Например, комичу main.c. Хуком обновляю текст в version.h.

main.c попадает в комит, а version.h нет.

Разбирался с этим вопросом пару лет назад, может уже что-то изменилось?

[KBH 0]

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

 

 

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

Хммм...

А это тогда что?

https://ru.m.wikipedia.org/wiki/Ос2000

 

[111 0]

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

Присоединяюсь к вопросу!

*****************

А вообще системы контроля сейчас ещё пока не развиты.

Они не имеют визуализаторов отличий, которые могли бы сравнивать семантику/логику работы версий программы.

 

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

 

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

 

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

 

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

 

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

 

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

 

 

Изменено 31 января, 2016 пользователем bbb

[x893 45]

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

[111 0]

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

Вы про что?

[AlexandrY 3]

Вы про что?

 

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

 

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

[111 0]

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

О том и речь.

 

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

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

 

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

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

 

 

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

 

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

 

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

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

 

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

 

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

 

А если бы мне дали не 2 версии софта написанного одним программистом, а целый репозиторий с 600 версиями, написанных разными программистами?

Ну с целью, чтобы я выяснил начиная с какой версии была привнесена бага.

 

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

[Corvus 1]

А если бы мне дали не 2 версии софта написанного одним программистом, а целый репозиторий с 600 версиями, написанных разными программистами?

Ну с целью, чтобы я выяснил начиная с какой версии была привнесена бага.

 

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

[111 0]

В реальной же жизни люди выстраивают процесс разработки так

-----

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

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

Тут уже выше писали, что "если мозга нет - ничего не поможет".

------

К несчастью таких программистов 99%.

И разбираться в репозитории что же они наваяли - это ацкий ад

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

Изменено 1 февраля, 2016 пользователем bbb

[Corvus 1]

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

 

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

[111 0]

Миллионы программистов по всему миру прекрасно работают с CVS

Миллионы мух не могут ошибаться?

Мыши плакали, кололись - но продолжали есть кактус?

Вы считаете что функционал современных систем контроля версий иделально удобным для работы?

А я считаю как и AlexandrY, что пока что: "Контроль версий это механизм делающий что угодно, но только не контроль версий в истинном смысле понятия <контроль>".

И повторю что говорил:

1) системы контроля сейчас ещё пока не развиты.

Они не имеют визуализаторов отличий, которые могли бы сравнивать семантику/логику работы версий программы.

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

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

 

 

и даже не подозревают о таких проблемах с повальным переименованием переменных и т.д. :rolleyes:

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

 

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

Любой инструмент должен облегчать труд разработчика, а не усложнять его. Так?

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

 

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

 

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

Изменено 1 февраля, 2016 пользователем bbb