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

Я не путаю. Но могу сказать, что твои представления о реальных ФС довольно фантастичны.

После того, как ты пояснишь свою.

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

Обоснуешь, что VCS не оказывает помощи при разработке.

А где я утверждал обратное?

складывает впечатление, будто git писали умственно отсталые школьники

:) Вы очень недалеки от правды. Судя по качеству Линукса, его разработчик прогулял все уроки, какие мог. Взрослых дядь не слушал. В результате, создал монолитную кучу нескажучего, которая, как ему кажется, приносит fun. А чтобы «фун» и дальше «фунял», слепил сам себе «закос под DVCS». Ожидать чего-то от «версионника одного человека» я б не стал, что и показала история и результаты сравнения с Hg.

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

Ты (намеренно?) путаешь необходимое и достаточное.

Обоснуешь, что VCS не оказывает помощи при разработке.

А где я утверждал обратное?

Вот:

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

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

Ты (намеренно?) путаешь необходимое и достаточное.

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

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

Так где противоречие?

но с его помощью ничего не разрабатывают

То есть методика хранения исходников и CI не относятся к процессу разработки? Только голое написание кода? Окей, твой посыл ясен, мы просто разные вещи вкладываем в понятие «разработка»

что и показала история и результаты сравнения с Hg.

Результаты сравнения показывают, что mercurial тормознее git. История показала, что mercurial используют реже, чем git.

p.s. Вчера ребенок не мог выключить комп под windows 10 - никакой реакции на пункты user и power в меню start. Вот это я понимаю - качество и стабильность от профессионалов своего дела.

мне просто некогда сейчас заниматься копанием в доках, но я тебя уверяю - ФС _без_ коррекции ошибок - это самое дебильное, что можно сделать после Линукса

То есть ты не знаешь ничего о предмете спора, но мнение имеешь. Надеюсь, ты не называешь себя инженером.

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

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

То есть методика хранения исходников и CI не относятся к процессу разработки?

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

Только голое написание кода? Окей, твой посыл ясен, мы просто разные вещи вкладываем в понятие «разработка»

Похоже на то. Свою понимание я изложил чуть выше в этом же посте.

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

Что бы мне подтвердить свои слова, мне достаточно написать hello world с помощью любого текстового редактора и собрать его с помощью компилятора.
Что нужно сделать вам, что бы опровергнуть мое утверждение я даже не берусь представить.

В том то и дело, что для написания hello world и для разработки нормального ПО используется немного разный набор средств.

Да, безусловно, VCS, CI, IDE, отладчик и т.д. не являются необходимыми для написания ПО. В общем случае можно хоть в машкодах писать, если речь о низкоуровневом языке программирования. Нужно ли - вопрос другой :-)

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

Если увеличить проект до «помощник нужен», разработка в указанном режиме сильно усложнится. В реальности помощников бывает на порядки больше, и «достаточно» применимо только после «не».

Ну так для простого hello world даже редактор не нужен! Достаточно иметь шелл и компилятор. А что делать, если разработчиков несколько? Как им организовать совместную работу? Да даже при работе в 1 лицо иметь историю версий исходников очень полезно. По такому принципу - IDE не средство разработки, gdb - тоже (можно же отладочных выводов напихать в код)

Угу, с этим я и не спорю. Просто у нас несколько разный взгляд на эти вещи. Рад, что мы прояснили наши понятия :)

Если увеличить проект до «помощник нужен», разработка в указанном режиме сильно усложнится. В реальности помощников бывает на порядки больше, и «достаточно» применимо только после «не».

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

Если смотреть только на графики, то складывает впечатление, будто git писали умственно отсталые школьники на переменке после «информатики», а bitkeeper — профессоры и чемпионы по оптимизации.

BitKeeper-ом никогда не пользовался, сравнить git-ом не могу. Но сам git не производит впечатления инструмента, над которым много думали и который тщательно разрабатывали. Собственно, история его появления очень показательна. На какой день разработки git смог хранить сам себя? На четвертый? Или на пятый?

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

Вторая часть моего ответа - BitKeeper освободился (комментарий)

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

Скачивать удобней архив. tar.gz по ссылке есть.

>при должной мотивации не остановит ее

В какой-то момент «усложнений» наберётся на 24 человко*часа часа в сутки. Не позже этого проект становится «невозможным», т.е. инструментов «недостаточно».

Отсутствие системы контроля версий усложнит командную разработку, но при должной мотивации не остановит ее.

А я тогда утверждаю, что отсутствие редактора кода усложнит разработку, но при должной мотивации не остановит ее. Таким образом «доказано», что редактор не является средством разработки! Не говоря уже про zx-spectrum, где прогу можно набирать построчно в интерактивном режиме. Я более скажу - для разработки и компилятор не всегда нужен - приходилось разрабатывать проги на asm K580 на листке бумаги и вводить ее тумблерами на отладочной панели.

То есть ты не знаешь ничего о предмете спора

Тайл, если ты прыщавый задрот, вышедший попонтоваться, можешь прекращать спор прямо сейчас, потому что уже сильно потерял репутацию. Но в качестве жеста вежливости, оставляю тебе это: https://ru.wikipedia.org/wiki/Ext4 - кури пока не остынешь и не научишься вежливости. Ты так и не понял разницы между коррекцией и чексуммой, увы.

Результаты сравнения показывают, что mercurial тормознее git. История показала, что mercurial используют реже, чем git.

А я это знаю и даже не спорю! НО! Это ровным счётом никак не коррелирует с качеством и удобством! Ну вот честно, мои коммиты проходят за несколько секунд, дольше пишу комменты к ним, чем собственно процесс аплоада. Скажи, это сильно тебя напрягает? А узкий круг использования... ну что ж, я никогда не мерял качество количеством. Тем более, когда «большинство» по всем критериям является чуть более, чем понтующимся, безмозглым планктоном. Есть единицы людей на сотню, чьё мнение можно считать компетентным - неужели я буду ориентироваться на оставшиеся 99%??
Есть ещё более смешной, но не менее интересный критерий: если ты юзаешь софт и тебе хочется его переписать - это хреновый софт! Так вот с Hg меня всё устраивает - может расширил бы его слегка, но в целом он мне нравится. А от Git убежал как от чумы даже несмотря на «функционально похожий» продукт.
Тут уместна ирония с ковчегом и Титаником: ковчег делал дилетант и возил лишь зверьё (да и то только в библейской сказке). Титаник делали профи и он утонул не сам, а из-за безалаберности команды. Так вот git - это ковчег, на котором я не хочу плыть!

В какой-то момент «усложнений» наберётся на 24 человко*часа часа в сутки. Не позже этого проект становится «невозможным», т.е. инструментов «недостаточно».

В какойто момент земля может наскочить на земную ось.

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

А что есть редактор кода?

Таким образом «доказано», что редактор не является средством разработки!

Пока нет определения редактора кода, доказательство так и останется в вашей голове.

Не говоря уже про zx-spectrum, где прогу можно набирать построчно в интерактивном режиме.

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

Я более скажу - для разработки и компилятор не всегда нужен - приходилось разрабатывать проги на asm K580 на листке бумаги и вводить ее тумблерами на отладочной панели.

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

Так вот с Hg меня всё устраивает - может расширил бы его слегка, но в целом он мне нравится.

Это хорошо, когда инструмент удовлетворяет всем потребностям пользователя.

А от Git убежал как от чумы даже несмотря на «функционально похожий» продукт.

Что же такого ужасного в гите?

Так вот git - это ковчег, на котором я не хочу плыть!

Лучше просто утонуть?

Все можно. Помню историю, произошедшую на заре информатизации. Коллега мой как-то архивировал весь винчестер (вот все 40 мегабайт) на стриммер (то-ли 5 мегов на ленту то-ли 8, сейчас не помню) с целью винт отформатировать.

Забекапил. Отформатировал. Поставил масадос. Дальше диалог — а где программа для стриммера? — Да вон, на пятой ленте!

Как-то мне эта история памятна... :)

если ты прыщавый задрот, вышедший попонтоваться, можешь прекращать спор прямо сейчас, потому что уже сильно потерял репутацию

Мне, в общем-то, пофиг.

в качестве жеста вежливости, оставляю тебе это: https://ru.wikipedia.org/wiki/Ext4

Фейспалм. Ты сам-то читал? «Вычисление контрольных сумм для записей журнала (англ. journal checksumming)». И всё. Данные не чексуммятся.

Что бы мне подтвердить свои слова

Тебе нужно было не подтвердить свои слова, а опровергнуть чужие.

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

Может он имеет в виду встроенные рейды btrfs/zfs ?

Не, ну кто-то же должен убить git, эту затянувшуюся финскую шутку?

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

Вот вам, человек не знает ни про машкод, ни про интерпретацию... Компилятор ему подавай, ламеру!

Тебе нужно было не подтвердить свои слова, а опровергнуть чужие.

Подтверждение моих слов опровергает чужие. Не?

Вот вам, человек не знает ни про машкод, ни про интерпретацию... Компилятор ему подавай, ламеру!

Что бы я делал без анонимуса?..

Не.

Ок.

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

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

BitKeeper-ом никогда не пользовался, сравнить git-ом не могу. Но сам git не производит впечатления инструмента, над которым много думали и который тщательно разрабатывали.

Применили опыт использования. И знания о реализации нескольких других. Думать уже не о чем было. Было нужно выбрать архитектуру и реализовать.

На какой день разработки git смог хранить сам себя? На четвертый? Или на пятый?

Торвальдс: Эх. Вы, кстати, можете видеть как всё приняло форму в репозитории исходного кода Git, за исключением первого дня или что-то около того.

Ждем ебыдлы?

Было нужно выбрать архитектуру и реализовать.

Что в переводе с финского звучит как «нефиг тут думать, трясти нужно» :)

После чего разрабы BitKeeper получают возможность сказать: если у вас реально большой репозиторий с длительной историей, то вот на таких-то сценариях у вас git будет сливать в разы.

Но куче разработчиков на это пофиг, т.к. Торвальдс, «git наше фсе», github стандарт де-факто, ну и решения о выборе VCS на проекте приняты давно и не ими :)))

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

И как это противоречит минимальному, но достаточному набору инструментов?

Что в переводе с финского звучит как «нефиг тут думать, трясти нужно» :)

После чего разрабы BitKeeper получают возможность сказать: если у вас реально большой репозиторий с длительной историей, то вот на таких-то сценариях у вас git будет сливать в разы.

В переводе для таких как вы это звучит так: Мы знаем недостатки такой архитектуры, но недостатки других архитектур для нас критичнее.

Если вы хотели перевести что-то для таких как я, то у вас не получилось. Я не понял, что вы хотели сказать, для кого какие недостатки критичны, а для кого нет.

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

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

Не дураки. Но вот получилось как получилось. И, поскольку писали в спешке и под свои личные цели, то получилось вот так.

Не дураки. Но вот получилось как получилось. И, поскольку писали в спешке и под свои личные цели, то получилось вот так.

Это ваше видение. Реальность от нее отличается.

Они исключили ряд внутренних недостатков BitKeeper'а. Это привело к худшим производительностям в ряду случаев. Ну и что? С чего вы решили, что в спешке и для своих нужд?

Вон в cvs теги можно в код встроить, а в git нет. Это недостаток git?

Это ваше видение. Реальность от нее отличается.

А вы, надо полагать, абсолютно объективны и ваше видение реальности ничем не искажено. Рад за вас.

Это привело к худшим производительностям в ряду случаев. Ну и что?

Ну и BitKeeper в этих случаях показывает лучшую производительность. Что вполне естественно. Но некоторые почему-то удивляются.

С чего вы решили, что в спешке и для своих нужд?

Из истории появления git-а.

Ну, за свободу!

unzip.zip

В текушем времени это не так смешно, когда есть инет, есть >1 компа, виртуалки и т.д. А вот я реально подобное в 90-х годах проделал, нужно было полностью переставить систему на втором харде места было мало-мало, поэтому я благополучно заархивировал все rar-ом, перелил на второй хард и после это форматнул, то что сам rar оказался в архиве я осознал поздно, дело было летом, большинство знакомых по дачам, t-mail и прочие терминалки так же в архиве, вобщем пришлось мне за rar-ом на другой конец москвы ехать :) Кстати шутки rar.rar в то время еще не существовало :)

В текушем времени это не так смешно, когда есть инет

Что толку от интернета, если unzip.zip лежит на 5.25" дискете? :)

Кстати шутки rar.rar в то время еще не существовало :)

Это потому, что тогда популярным был не zip и rar, а arj.

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

Так было и с CVS, и с SVN.

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

Я бы с удовольствием послушал пользователей, которые используют и git и bk. А бенчи от разработчика bk ни о чем.

Не дураки. Но вот получилось как получилось. И, поскольку писали в спешке и под свои личные цели, то получилось вот так.

Женя, с тех пор много воды утекло, может пора обновить git до текущей версии?