[Corvus 1]

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

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

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

 

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

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

 

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

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

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

 

[111 0]

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

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

Да их палкой не заставишь делать эту "лишнюю" работу

 

[111 0]

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

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

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

[dxp 53]

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

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

 

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

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

 

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

 

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

 

 

[ViKo 1]

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

Да их палкой не заставишь делать эту "лишнюю" работу

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

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

[andrew_b 15]

Методом половинного деления выбираем ревизию, и дальше делим верхнюю или нижнюю половину...

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

[ViKo 1]

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

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

[AlexandrY 3]

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

 

Упомянутый субъект не понимает, ...

Ваша проблема в том,

 

Это не наша, а ваша проблема.

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

 

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

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

 

Я использую по необходимости SVN, Git, Github и Mercurial

SVN это, конечно, анахронизм. Можно забыть. Просто легко было разместить сервер SVN

 

Git вынужденно использую из-за Github.

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

 

Лучше всех Mercurial выраженный в TortoiseHg. Работает хотя бы быстро и имеет свой клиентский менеджер. Держу в нем около 3-х десятков проектов.

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

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

Они даже тормозят в этом, из-за своего кривого пользовательского интерфейса.

 

 

 

 

[dxp 53]

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

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

 

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

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

 

[...]

 

Они даже тормозят в этом, из-за своего кривого пользовательского интерфейса.

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

[andrew_b 15]

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

git bisect

[111 0]

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

Расскажите подробней

 

 

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

 

Я пользовалься VCS лет 5. По полной программе. И в конце концов понял, что в том функционале, в котором они сейчас есть, ничего кроме доп. гемороя она мне не дает.

 

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

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

А какую же тогда функцию CVS Вы считаете основной/главной?

Позвольте предположу: обеспечивать READ ONLY доступ нескольким программистам к коду друг друга?

 

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

 

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

 

В TortoiseHg без комментария (описания) закоммитить не дает.

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

 

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

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

[ViKo 1]

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

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

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

 

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

[111 0]

dxp

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

[halfdoom 0]

Тогда зачем мне система КОНТРОЛЯ версий, которая ничего не контролирует?

 

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

[AlexRayne 7]

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

Они даже тормозят в этом, из-за своего кривого пользовательского интерфейса.

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