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


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


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

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

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


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

Не всех. Но 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

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

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

Сообщение отредактировал bbb - Feb 2 2016, 17:03

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

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

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

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

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