Какой (D)VCS Вы пользуетесь?

как раз чем больше проект - тем тщательнее надо думать.

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

Но staging area у git убога до удивления по сравнению с mq или подобными системами для самого git.

Можно подробнее?

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

Можно подробнее?

(И да, когда я говорил «хочешь ускориться — жмёшь «газ»», я не имел в виду скорость работы Mercurial. Я имел в виду простоту и разумность интерфейса — т.е. Вы скорее всего неправильно поняли аналогию про коробки передач. Хотя не спорю, что что-то в нём может быть неучтено.)

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

Похоже, то что нужно команде :)

Subversion отсосал даже у Mercurial.

Найс.

Планируемый объем изменений. Именно тот показатель, который отличает котропативное ПО (у меня) и встраиваемое (у Iron_Bug).

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

Вероятно проблема непонимания кроется в разнице терминологий. В git для этого используют коммиты. в локальной ветке, естественно. А staging area - это только то, что попадет в мледующий крммит.

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

git Другого ничего не знаю

Ну хоть один честный человек. Kudos to you.

Дизайн Monotone, ты хотел сказать

Это твоё личное впечатление или автор Git'а в какой-нибудь рассылке делился откровениями?

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

Вероятно проблема непонимания кроется в разнице терминологий. В git для этого используют коммиты. в локальной ветке, естественно. А staging area - это только то, что попадет в мледующий крммит.

Вот да. Какой смысл иметь стек в «предкоммитной области»? Если что, есть стек в stash для мусора-который-пусть-пока-где-то-поваляется; если локальные ветки, из которых можно пушить/мержить/черрипикать. И так всё довольно сложно, куда дальше-то...

мусора-который-пусть-пока-где-то-поваляется

Вот и всё отношение к разработке.

Это твоё личное впечатление или автор Git'а в какой-нибудь рассылке делился откровениями?

Автор.

Вероятно проблема непонимания кроется в разнице терминологий.

Нет. Я умею в git, если что.

У TortoiseGit тоже эти diff-скрипты для офисных форматов в комплекте идут.

Вот, кстати. На днях искал подобный скрипт для hg и open office на linux, что-то ничего рабочего и не нашел. Там может и работы немного сделать, но не до этого было. Рабочее никто не встречал?

Я так понимаю, рабочий он потому что ты его никому не показывая сама проверила?

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

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

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

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

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

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

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

Слишком толсто и слишком оффтопик.

Какой смысл иметь стек в «предкоммитной области»?

Такой, что в hg без костылей расширений нельзя редактировать коммиты и стэша нет. Исторически так сложилось, что для решения этой проблемы были изобретены разные велосипеды. Стек в «предкоммитной области» - один из них.

Исторически так сложилось, что для решения этой проблемы были изобретены разные велосипеды. Стек в «предкоммитной области» - один из них.

Это случай так называемого вранья.

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

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

мне кажется, аналогия протестированного программистом кода и похода на горшок, объясняет вообще все.

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

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

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

программирование - это не продукт коллективного разума (иначе не было бы багтрекеров

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

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

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

Это случай так называемого вранья.

Озвучьте, пожалуйста, правду.

Стек патчей - это стиль работы, изобретенный задолго до git и mercurial, и реализованный в, например, quilt.

https://lwn.net/Articles/13518/, см. Conepts.

The key philosophical concept is that your primary output is patches. Not ".c" files, not ".h" files. But patches. So patches are the first-class object here.

Ну да, стиль изобретен давно. В git он реализован коммитами, а в hg, как многим тут кажется, костылями.

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

Я вот и пытаюсь узнать о предмете у поклонников hg, а в ответ получаю пафос и оскорбления.

В git он реализован коммитами

В hg, внезапно, тоже.

в hg, как многим тут кажется, костылями.

Казаться это может только по невежеству.

Ты не пытаешься ничего узнать. Ты мелко троллишь и при этом строишь из себя оскорбленную невинность.

Простите, так его (стэка патчей) в git нет, или он, внезапно, реализован так же как в hg?

По результатам этого и двух других предыдущих опросов: https://www.dim13.org/images/lor_vcs.png

Еще бы точки отметить, чтобы видеть где данные, а где экстраполяция/интерполяции

Лень переделывать и возиться с gnuplot. Точки: 2008, 2013, 2016, по вертикале — проценты. И тут IMHO главное тренд, а не точные цифры.

По картинке кажется, что ртуть в 2014 пережила пик и пошла на спад. Но, думаю, что в репльности просто остановила рост.

Sad, but true.

Есть ли какой-нибудь не слишком объемный документ по переходу с git на hg, вроде того что Джоэль Спольски писал для перехода с svn?

Совсем простенький: https://www.mercurial-scm.org/wiki/GitConcepts

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

Я никогда не понимал, зачем в гите staging area. Ну т.е. на практике, конечно, понимал и использовал — но с моей точки зрения, это костыль, который используют за неимением лучшей системы.

С моей точки зрения всё должно выглядеть так: никакие staging area, стеки патчей, «git stash»/«hg shelve» не нужны. Достаточно лишь рабочей копии (РК) и дерева коммитов. Если хочешь — ты все изменения c РК коммитишь в дерево; если хочешь — только часть (часть остаётся в PK); если хочешь поиграться с очередями патчей — просто создаёшь временные коммиты в дереве, редактируешь/rebase-ишь/мучаешь их как хочешь, пока они не придут в нужную кондицию (и тогда превращаешь в постоянные или удаляешь).

В Mercurial оно приблизительно так и сделано:

• хочешь закоммитить всё — «hg commit -A»;
• хочешь закоммитить часть — «hg commit -i» (я не использовал, недавно появилось) или «hg record» (да, extension, но в hg без них никуда) или в простых случаях достаточно «hg commit files» или «hg crecord» (extension, TUI, не юзал) или юзаешь GUI — на твой выбор;
• хочешь играться с очередями патчей — «hg commit -s ...» ("-s" — это "--secret") и вперёд: rebase, graft, histedit, strip или даже MQ.

В Mercurial коммиты бывают трёх видов: secret, draft, public. Secret — это когда ты локально что-то для себя коммитишь, чтобы поиграться (ты его не можешь за-push-ать в другой репозиторий). Draft — это «обычные» коммиты, ты их можешь amend'ить («hg commit --amend») и другими способами редактировать (см. выше), пока никуда не за-push-ал — как только за-push-аешь, они, как правило, автоматически становятся public (если целевой репозиторий не настроен как "[phases]\npublish=False\n"). Public — это то, что ты уже «не можешь» редактировать, высеченные в граните коммиты (на самом деле, конечно, можешь: «hg phase -f -d commits» — и hg считает, что эти коммиты ты никуда не push'ал).

Разве что инструменты редактирования коммитов в Mercurial, на мой взгляд, оставляют желать лучшего (по крайней мере, когда я его в последний раз юзал, скажу честно — давно). И про extension-ы — ты так говоришь, будто бы это что-то плохое; extension-ы — норма. Наиболее популярные из них (а выше назывались команды только из популярных) даже распространяются в комплекте с Mercurial (при включении не нужно указывать путь, не "[extensions]someext=path1\notherext=path2\n", а "[extensions]someext=\notherext=\n").

Спасибо за развернутый ответ.

Разделение на secret, draft и public звучит правильно, хотя с git'овской колокольни, кажется лишней сущностью.

В общем, я лишний раз утвердился во мнении, что решение в споре git vs hg (также как и C vs Python) скорее психологическое тем техническое. Деформация моей психики ближе к стороне Торвальдса и Ритчи. И это прекраснейшая сторона оперсорса, что каждый из нас может найти инструмент, который не только решает задачу, но комфортен.

PS Про extension-ы не я говорил

Очевидно, с тех пор ничего не изменилось.

Очевидно, с тех пор ничего не изменилось.

(: Какой (D)VCS Вы пользуетесь? (комментарий)

Потому что нормальные люди для этого ветками пользуются

Фигасе, не ожидал такого количества хипстеров!

Для чего «этого»?

Для хранения цепочек локальных патчей.

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

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

А для коррекции конкретных патчей редактировать историю?

Да, до тех пор, пока фича не доделана