О том и речь.

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

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


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

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

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

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

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

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

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

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

-----

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

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

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

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



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


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

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

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

Ваше право. Сделайте лучше или хотя бы научитесь пользоваться тем, что есть.


Комментарии перед коммитом нужно писать.


В разработке ВСЁ определяется именно человеческим фактором. Поэтому программисты и получают прилично.

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

Вообщем, объясните своему 50-ти летнему дедушке это так:

Не всех. Но Git близок к идеалу.


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

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

Исторически сложилось, что подавляющее число систем управления версиями разрабатывались для работы с текстом в простом (ASCII) формате, написанном, главным образом, руками, поэтому встроенные компараторы (чекеры изменений) сделаны на основе простого текстового сравнения. Если вам нужно сравнивать не текстовые файлы, а двоичные в каком-то проприетарном формате, ну так и озаботьтесь поиском/разработкой соответствующего компаратора, который бы на мелкое изменение (например, позиционного) выдавал короткий "patch", описывающий именно это изменение, и способный применять такие патчи к в файлам в этом формате. А уж функционал именно системы управления версиями - это вещь совершенно перпендикулярная этому. Имея такой компаратор, несложно его "прикрутить" к любой современной системе управления версиями (через механизм хуков), так чтобы VCS автоматически вызывала компаратор и сохраняла только изменения (а также "умела" их показывать - опять же с помощью этого стороннего, эффективано заточенного под свою задачу, инструмента).

В TortoiseHg без комментария (описания) закоммитить не дает. По этим комментариям должно быть видно, что изменилось.
А искать на каком этапе выскочила ошибка - просто. Методом половинного деления выбираем ревизию, и дальше делим верхнюю или нижнюю половину...

Git это делает сам.

А как он узнает, что вам нужно?

Это не наша, а ваша проблема.
Как развивались контроли версий мы и без вас узнаем в гугле.

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

Я использую по необходимости SVN, Git, Github и Mercurial
SVN это, конечно, анахронизм. Можно забыть. Просто легко было разместить сервер SVN

Git вынужденно использую из-за Github.
А так под Windows это тормозной и неудобный инструмент даже с GitHub десктопным клиентом. Но может разовьют, кто знает.

Лучше всех Mercurial выраженный в TortoiseHg. Работает хотя бы быстро и имеет свой клиентский менеджер. Держу в нем около 3-х десятков проектов.
Резервное копирование действительно удобнее чем используя файловые менеджеры, правда жертвую огромным дисковым пространством и замедлением поиска по диску из-за раздувания структуры служебных директорий требуемых для контроля версий.
Откаты на предыдущие версии использовал всего в нескольких случаях. И именно потому что контроль версий никак не помогает анализировать различия.
Они даже тормозят в этом, из-за своего кривого пользовательского интерфейса.

Пока что видно, что не помогло.


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

git bisect

Ну напишет программист "комментарий": "тут байда какая-то", " тут правим ту самую хрень".

Вам очень понятно будет по таким камментам что изменил программист?

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

Я сам себе комментарии пишу, чужих мне не надо.

dxp
И атомарность/транзакционную законченность изменений кода перед коммитом программист должен проверять вручную. Тогда зачем мне система КОНТРОЛЯ версий, которая ничего не контролирует?

А кто вам сказал, что она должна контролировать? Version control system это "система управления версиями" и с этой задачей большинство современных систем прекрасно справляется. То же, о чем вы говорите - "бросить взляд", это относится к семантическому и контекстному анализу различий. Для этого гуглится другой инструментарий, специфичный для каждого вида исходных файлов. Но больше чем уверен, что с подходом "бросания взглядов", вы не найдете ничего подходящего.

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

И между чем же ?
Похоже вы как собака, все понимаете, но сказать не можете.



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

А что за приятные расширения?
Я там пользуюсь двумя-тремя командами.

Могу много чего сказать на тему, но только человеку, который хочет в этом разобраться, а не троллить как вы. Оставайтесь при своём.



Вот именно.

dxp абсолютно прав. Если грамотно использовать тот же git, можно вообще писать программы, применяя нужные патчи, вместо написания кода В git каждый день создается по несколько веток для самых небольших задач, когда они решаются, ветки сливаются и удаляются. Если же просто бэкапить туда (такой метод использования вполне уместен), то действительно при гигабайтных архивах хранилище превращается в помойку, в которой сложно что-то искать.
В том-то и дело, что освоив git, Вы получаете мощнейший инструмент по разработке, меняющий Ваш workflow и экономящий время. Сейчас сам осваиваю. Раньше был сторонником SVN с бэкапами, но сейчас понял, что лучше потратить немного времени, чтобы потом оно с лихвой окупилось.

Тогда видимо надо уточнить что вы собственно программируете.
Что такое "задача" в вашей технологии? Почему им нужны ветки?
Вам мало дерева проекта в собственной IDE?

Проверьте размер ваших служебных файлов системы контрооя версий. Они действительно меньше гигабайта?
Какой размер проекта тогда у вас и насколько длинная его история?

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

Мне это высказывание напоминает вот такую позицию некоторых людей:
"Я не нашел никакого способа или технологии, которые позволили бы с помощью RTOS экономить ресурсы процессора, они всегда осью только отнимаются."

Прям один в один аналогия

ЦОС. Микроконтроллер с ОС осуществляет управление аппаратной частью, в которой реализавана высокоскоростная обработка, а также много чего непосредственно на нем производится (для задач с меньшей частотой).

Идеология Git такова, что любое исправление или добавление пусть самой маленькой функции в несколько строк вполне считается задачей. Для нее делается ветка, в которой отлаживается все. Параллельно приходит задание починить что-то другое, срочно. Для чего из master создается ветка, в которой происходит исправление бага. Затем после отладки сливается на сервер ответственным за данный репозиторий. Таким образом, master всегда в том состоянии, что из нее можно генерировать прошивку. Там нет чего-то такого, что положит проект на некоторое время. Менее квалифицированные сотрудниики не внесут катастрофических изменений.
Например, на Хабре описан стиль такой работы: https://habrahabr.ru/post/75990/

IDE здесь ни при чем.


Нет, больше. Проекту несколько лет. Только Git используется именно как инструмент, позволяющий эффективно вести работу.



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

P.S. Я не настаиваю использовать системы управления версиями именно таким образом. У каждого могут быть свои представления. Попытался объяснить преимущества именно такого подхода, под который создавалась сама система.

Я уже долблю несколько постов подряд. Меня не интересует командная работа!

Я изучаю вопрос что дает контроль версий индивидуальному разработчику или разработчику слабо связанному с командой.
Или что он дает разработчику вне рамок взаимодействия с командой.
Что контроль версий может предложить для повышения личной производительности. За команду пускай думает начальство.

Ветки для пары изменений пока выглядят в личном плане как критическое излишество.

И что такое "бэкпортирование"?
Как контроль версий помогает портированию?



Это абсолютная правда. RTOS экономит ресурсы разработчика, а не процессора.

Наверное, в этом случае выгод будет меньше. Навскидку приходит только такая ситуация: допустим, вы захотели что-то изменить в проекте, работаете над этим изменением, в это время заказчик сообщает об ошибке. У вас сейчас в основной ветке не совсем рабочая версия, поскольку что-то допиливате. А вдруг обнаружится 2-3 ошибки. Тогда лучше master не трогать, для каждой проблемы создать ветку, а потом уже слить воедино. Не стоит бояться такого числа веток. Их может быть параллельно десяток. После того, как вы отработали и слили ее, она запросто удалается.


Откат к более страым версиям проекта: https://ru.wikipedia.org/wiki/Бэкпорт. За время работы многое в текущих проектах ушло вперед, но есть некоторые места, которые лучше были сделаны в самом начале, со временем вынужденно проводились в них изменения. Все работает, но хотелось бы именно начальный вариант получить. Теперь для других проектов хочется получить то состояние и развивать проект дальше.

Так говорите, будто Вас кто-то заставляет. Инструмент выбирается под задачу. При работе в одиночку, да на одной машине можно обходиться и бэкапами + лог изменений в текстовичке. Раньше тоже так делал и особых проблем от этого не испытывал.
Но когда привыкаешь работать с контролем версий в команде, то и для одиночных любительских проектов использую контроль версий на личном сервере. Чтоб привычный порядок работы не нарушать.
По мне, до любой технологии надо "дорасти". Когда уже сам понимаешь, что какая-то вещь тормозит работу, увеличивает вероятность ошибки, отнимает лишнее время и т.д. - тогда и надо искать пути решения. Будь это контроль версий, баг-трекер, система постановки задач, база данных применяемых компонентов, вот это всё.

"Контроль версий" следовало бы переименовать в "контроль программиста".
Так как только в этой ипостаси и только в крупных проектах (которые пишутся коллективом программистов) использование это программы хоть сколько то оправдано.

Я же поюсав VCS пару лет пришел к выводу, что мне проще просто сохранить исходник под именем? в котором в конце я добавлю [2], [3] и т.д. для обозначения, чем использовать этого монстра, НАПРАСНО жрущего мое время (которое как известно деньги) и ресурсы компа

И если мне нужно будет выяснить/вспомнить "что же я поменял" я запущу Araxis и сравню исходники с разными цифрами в []


Вы так и не объяснили в чем же ГЛАВНОЕ назначение VCS.
Хотя постоянно намекаете, что знаете это.
Просвятите же нас.


И это называется "инструмент УПРОЩЕНИЯ работы программиста"



Короче получается КАША из кучи старых и новых версий программы.
У меня язык не поворачивается назвать это "упрощением работы программиста"

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

расширения меркуриала без которых работа становится черной - mq, shelve, record, rebase, transplant. - они удачно представлены в УИ тортилы и смотрятся как родные.
насколько я осведомлен, гит тоже может иметь такие расширения, но то что я имею из коробки - без оных.

Почитал я про эти расширения. Они относятся все к той же истории с патчами и кучей веток.
Но контроль версий слишком неповоротлив для оперативной работы на таком уровне. Надо сильно чего-то бояться чтобы тратить время на ветки и патчи.

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

Это вы имеете ввиду папку .git в директории проекта, она занимает гиг?

1) идеология патчей как раз позволяет избавиться от кучи веток - вы делаете работу, собирая вв стеком патчей. это еще не комит. после того как все готово, патчи чистится от мусора, реорганизуются к красивому виду и комитятся в историю. это так я их использую.
2) инструменты shelve, record - позволяют делать красивые комиты очищеные от мусора, и совсем необязательно в патчи. а rebase - как раз врезать отдельную ветку в линейную историю - тоесть устранять ветвистость.
3) без ветвистости никак не поулчается работать если Вы работаете с кодом которым пользуется ктото еще. а этих проектов у меня большинство. прелести ветвистости начинают вылезать когда надо свои правки слить с чужими, вот тут собственно СКВ и начинает экономить время.

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

За рефакторинг вообще надо бить руки. хотя видимо я старикан перхотный гдето за спиной Линуса остался, уже и не понимаю всей мощи современного программиста - как же он работу себе организует если не через рефакторинг.
Я даже больше припомню - Линус стонал что С++ - зло. и зло в нем именно его продвинутости - перегрузка всего всего и абстракция/виртуальность. ибо эти фичи позволяют делать код в котором одними и теми же словами написано разное. автоматы сшивания патчей на таких местах легко делают ошибки, которые почти нереально искать если компилятор сразу незаругался.

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

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

AlexRayne
А если ты пишешь код под венду?
То тебе не просто код нужно будет откатить, но и венду вернуть в то состояние, при котором, код якобы работал нормально (ведь возможно баг появился не потому что ты что-то не правильно в коде сделал, а потому что в венде что-то поломалось или в среде разработки).

CVS откатить венду и среду разработки не позволяет.

Поэтому я и использую RollBack Rx v9.1 если мне нужно откатиться к стабильной версии

ветка просто пылает стульями людей, так и не разобравшихся ни в git, ни в, хотя бы, svn.


да-да, вообще учиться - это плохо.

Не согласен.
Рефакторинг - двигатель прогресса.
Ибо, ну не может человек сразу взять... да и сделать изделие/продукт так, чтобы было "не убавить не прибавить". Т.е. чтобы были одни достоинства и не было недостатков. Ибо человек не Бог.

В противном случае придумав автомобиль человек сразу бы сделал 600-й мерс. А он (600-й мерс) по факту появился только через почти 100 лет после изобретения первого автомобиля.
И только благодаря постоянному и непрерывному "рефакторингу" в автомобильной отрасли.




Ну почему же. Я Tortois SVN честно использовал года два. Лет 10 назад.
Т.е. я с полной самоотдачей пытался "быть в струе" прогресса.
Пока наконец не устал и не понял, что львиная доля моих усилий и моего времени уходят в пустую: вместо того, чтобы полностью сосредоточиться на коде я был вынужден вникать и разбираться тонкостях (и постоянно держать их в голове) в перепетиях SVN

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

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

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

уже купили?

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

подозреваю, что для вас прогресс - это такая же программа, но безвозмездно, т.е. даром.

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

Я, как Subj, подхожу по всем критерям к теме
Поэтому тупой вопрос по SVN (скорее по евойному клиенту)
----------------
Как в установленном SVN / Tortoise отключить проверку правописания в окне диалога комментариев-лога ?

В док указано что надо для установки локализации и словарей.
А вот как ее прибить - непонятно.

Нажать F1 ?

Ну чтож. Жмем. С помощью поиска по F1 "spellchecker"
находим эту хорошо запрятанную услугу.
Settigs -> Dialog2