Здравствуйте, alex_public, Вы писали:
_>>>А, всё, я понял что ты нарисовал. Правда не знаю зачем применять для такого именованные ветки (когда нет реальных разветвлений), но если очень хочется, то в mercurial можно без проблем и оно прямо так и будет выглядеть. ) _>·>Потому что ветки обычно имеют некий смысл, связанный с процессом разработки, а не с текущей структурой истории. Нужны же ветки для того, чтобы понимать что у нас сейчас release, а что development. А разветвление расхождение веток это текущее состояние истории. _>Эм, а какой смысл имеет последовательная группа ревизий с меткой "release"? ) Release — это же обычно некий фиксированный момент времени, а не интервал. Соответственно в репозитории это соответствует одной выделенной ревизии. Обычно её или помечают соответствующим тегом прямо в основной ветке или же создают отдельную ветку с именем release, в которую изредка (как раз в моменты времени релиза) сливают результаты из основной ветки. А то, что показал ты, я никогда не видел и пока не могу представить для чего оно может понадобиться.
Да, смысла меток на ревизиях нет, поэтому подход hg и является не самым осмысленным.
Ладно. Давай заменим "release" на "release_candidate", чтобы тебе понятнее было. Т.е. мы хотим знать какую ревизию мы сейчас тестируем более тяжелыми тестами (ручное или soak тестирование, например).
А тегом помечаются конкретные номера публичных версий, и теги — read-only.
_>>> И даже меньше команд чем в git понадобится. ))) _>·>Покажи, плз. Насколько я знаю в hg без коммита ветку не создать. _>Нельзя) Но у тебя же там как раз последовательность фиксаций нарисована. )
Что за фиксации? Ревизии в смысле? Ревизия это коммит, т.е. патч+автор+етс. Создание ветки это только в hg является коммитом, что опять фигня какая-то.
_>·>Мой вопрос в том, что имеется в виду в приведённой тобой документации: «"line of development" is a linear sequence of consecutive changesets». Где в приведённом мной графе истории line of develpment? Что есть head? Что есть branch? _>"line of develpment"=="branch" (который реальная ветка, а не атрибут branch name). Ну а head — это последняя ревизия в ветке.
Плиз, на моём графе отметь все эти понятия.
_>>>Я вообще то про Mercurial и говорил. ))) _>·>Ааа. Понял. Хорошо, как в mercurial отличать мой "experiment" от твоего? _>Ну например по автору и по предку (в GUI по положения в дереве).
"автор" не годится. Я могу продолжить твой эксперимент и накоммитить туда что-нибудь, и даже обратно тебе потом запушить.
"предок" уж тем более не годится, т.к. мы можем начать свои эксперименты от одной и той же ревизии, скажем, последнего публичного релиза.
Ещё что-то есть?
_>·>А как тогда такую историю создать? _>·>
_>Я так и не понял, зачем ты хочешь применять ветки там, где нет развилок? )
Не "нет развилок", а может не быть развилок. Даже hg это упоминает: "A new branch name can be started in the middle of a development line, not necessarily at a diverging point". Но начало именованного бранча это уже коммит, а поэтому история уже разъедется. Бардак жуткий.
_>·>Или, иначе говоря, выразить тот факт, что мы зарелизили всё что надевелопили. _>Ну поставь на последнюю ревизию тег "release 2.0" и всё. Или же организуй отдельную ветку с релизами. Я уже писал выше.
Теги для конкретных версий, а не для процесса релиза.
_>>>
_>>>As such, each changeset in Mercurial forms an element of a branch. A changeset thus can be said to "belong to a branch". Per that definition, a branch is simply a linear sequence of changesets.
_>>>Ещё требуются пояснения? ) Думаю вполне видно, что никаких намёков на именованные ветки тут нет. _>·>Не осиливаю потому что полная мешанина из терминов. Чем тогда бранч отличается от "line of development"? _>Ничем и не отличается.
Ок, если не отличается, значит одно можно заменить на другое, смысл меняться не должен. Давай попробуем. Возьмём
"Branches occur if lines of development diverge"
заменяем
"Branches occur if branches diverge"
Теперь объясни смысл этого предложения.
_>>>Это не отдельная сущность, а просто название ревизии без потомков. Т.е. этот "термин" можно спокойно и в git применять. ))) _>·>Бранч может иметь несколько их. В этом и путаница, которая требует новой сущности. В гите этот термин бессмысленен. _>Не может. ) Несколько голов может иметь виртуальная (потому как в реальности её не существует, а есть несколько веток с одинаковым атрибутом "имя") сущность называемая named branch.
Почему тогда без этой виртуальной сущности hg, как ты говоришь, не сможет функционировать?
_>>>Кошмар, кошмар. ))) Нельзя ничего добавлять в систему для удобства пользоваться. Пускай он лучше побольше сам работает, не развалится, да? ))) _>·>Конечно нельзя, если можно не добавлять, иначе Оккам бритвочкой полоснёт. Никакого удобства.. путаница только — вроде бы и тег, но какой-то особенный... _>Он не особенный, а просто устанавливаемый самой системой (а не пользователем). ))) Автоматика... ) Можешь сам такое сделать хуками в том же git'e.
Вот это и плохо — понятие тег в hg тоже особенное.
_>·>Я не понял какой ты делаешь вывод и причём тут архитектура. Чем ты объясняешь разницу в размере? _>Разными алгоритмами и форматами хранилища.
Разница между алгоритмами bzip2 и gzip не является достижением hg. А форматы тут причём? Какие форматы? Как они влияют на размер?
_>>>У тебя всё верно, но я говорю об измерение пакетов с двумя ревизиями. ) И от чего по твоему оно зависит, если нет архитектуры системы? ) _>·>Мне кажется, что просто разный алгоритм компрессии применён (команды hg выполнялись медленее раза в два), надеюсь это он компрессией занимался. _>·>Да, точно. Почитал доку на hg bundle и обнаружил флажок -t. Если добавить "-t gzip", то размер становится 228763 (напоминаю что у git было 228253). Ы? _>А можно узнать флажок в git, который позволит добиться результата mercurial? )
Не знаю, гугленьне не помогло. Наткнулся только на "The way git normally stores data is using zlib, which, on the tradeoff of performance vs. efficiency, is very fast but not very efficient. It does this because the difference is normally not sufficient that it is worth making operations on the contents of the repository (diffs, merges, etc.) require a large amount of either CPU or memory."
И да, git работает быстрее.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
_>>Эм, а какой смысл имеет последовательная группа ревизий с меткой "release"? ) Release — это же обычно некий фиксированный момент времени, а не интервал. Соответственно в репозитории это соответствует одной выделенной ревизии. Обычно её или помечают соответствующим тегом прямо в основной ветке или же создают отдельную ветку с именем release, в которую изредка (как раз в моменты времени релиза) сливают результаты из основной ветки. А то, что показал ты, я никогда не видел и пока не могу представить для чего оно может понадобиться. ·>Да, смысла меток на ревизиях нет, поэтому подход hg и является не самым осмысленным.
Какой ещё подход hg? ) Это же ты предлагаешь такую схему. )))
·>Ладно. Давай заменим "release" на "release_candidate", чтобы тебе понятнее было. Т.е. мы хотим знать какую ревизию мы сейчас тестируем более тяжелыми тестами (ручное или soak тестирование, например).
Так, давай разберёмся подробно что же ты собственно хочешь. Эти метки должны изменяться со временем или нет? Метка должна быть на одной ревизии или на последовательном их наборе? Ветвление (реальное) требуется или нет? )
·>А тегом помечаются конкретные номера публичных версий, и теги — read-only.
Ну так это смотря где))) В Mercurial они вполне редактируемы. )
_>>Нельзя) Но у тебя же там как раз последовательность фиксаций нарисована. ) ·>Что за фиксации? Ревизии в смысле? Ревизия это коммит, т.е. патч+автор+етс.
Что-то у тебя проблемы не только с пониманием документации Mercurial, но и вообще с переводом английского текста на русский. Commit — это действие (глагол), переводим как фиксация. А changeset — это объект (существительное), переводим как ревизия. Ну а слова "коммит" в русском языке нет и уж тем более в виде существительного (если уж и использовать подобный англицизм, то он должен быть глаголом).
·>Создание ветки это только в hg является коммитом, что опять фигня какая-то.
Только наоборот. Фиксация ревизии порождает ветвление (при условие наличие у текущей ревизии другого потомка) и это абсолютно логично.
_>>·>Ааа. Понял. Хорошо, как в mercurial отличать мой "experiment" от твоего? _>>Ну например по автору и по предку (в GUI по положения в дереве). ·>"автор" не годится. Я могу продолжить твой эксперимент и накоммитить туда что-нибудь, и даже обратно тебе потом запушить. ·>"предок" уж тем более не годится, т.к. мы можем начать свои эксперименты от одной и той же ревизии, скажем, последнего публичного релиза.
Скорее всего так и будет. Но при этом в визуальном дереве всё будет чётко видно и отделено. )
_>>Я так и не понял, зачем ты хочешь применять ветки там, где нет развилок? ) ·>Не "нет развилок", а может не быть развилок. Даже hg это упоминает: "A new branch name can be started in the middle of a development line, not necessarily at a diverging point". Но начало именованного бранча это уже коммит, а поэтому история уже разъедется. Бардак жуткий.
Я вообще то и не говорил, что это в Mercurial невозможно (более того, выше я упоминал, что это реализуется даже меньшим числом команд, чем в git). Я спрашиваю про другое — зачем может понадобится подобная бредовая конструкция? )
_>>·>Или, иначе говоря, выразить тот факт, что мы зарелизили всё что надевелопили. _>>Ну поставь на последнюю ревизию тег "release 2.0" и всё. Или же организуй отдельную ветку с релизами. Я уже писал выше. ·>Теги для конкретных версий, а не для процесса релиза.
Понятие "процесс релиза" в контексте систем контроля версий по прежнему остаётся для меня загадкой. )))
_>>·>Не осиливаю потому что полная мешанина из терминов. Чем тогда бранч отличается от "line of development"? _>>Ничем и не отличается. ·>Ок, если не отличается, значит одно можно заменить на другое, смысл меняться не должен. Давай попробуем. Возьмём ·>"Branches occur if lines of development diverge" ·>заменяем ·>"Branches occur if branches diverge" ·>Теперь объясни смысл этого предложения.
Ветвления происходят при разделение веток. )
_>>·>Бранч может иметь несколько их. В этом и путаница, которая требует новой сущности. В гите этот термин бессмысленен. _>>Не может. ) Несколько голов может иметь виртуальная (потому как в реальности её не существует, а есть несколько веток с одинаковым атрибутом "имя") сущность называемая named branch. ·>Почему тогда без этой виртуальной сущности hg, как ты говоришь, не сможет функционировать?
Ээээ что? ) Я как раз наоборот всё время говорю, что mercurial можно удобно пользоваться вообще без затрагивания "имён для веток"/закладок/тегов, работая только с чистыми базовыми ветвлениями (естественно анонимными) на основе ревизий. Т.е. в основе лежит именно это, а поверх накручены дополнительные опциональные удобства (имена для веток/закладки/теги).
Здравствуйте, alex_public, Вы писали:
_>Ну как видишь никаких ограничений нет на самом деле (и я кстати об этом говорил изначально). Есть только разница в удобстве (причём в пользу Mercurial). Люди даже подобные https://www.mercurial-scm.org/wiki/GitConcepts#Command_equivalence_table таблички соответствия команд делают. ))) Но опять же там есть не все команды (например нет heads) из-за отсутствия в конкуренте соответствующей концепции (типа анонимных веток).
Вот тут на родственном форуме (если ты в РФ, то без Tor не прочтёшь) коллега Lyubomyr Shaydariv пишет (месяца 3 назад, так что актуально):
Я справді дуже люблю hg, і для своїх особистих проектів надаю йому перевагу, а не git, проте з часом я маю все ж деякі розчарування стосовно нього. З ходу можу назвати наступне:
* Відсутність staging area. В git її наповнювати можна в імперативній формі, і згодом видалити із неї файли, випадково туди занесені. Писати hg commit із складним фільтром для комміта важко, і виправляти такий комміт незручно або важко (як і через hg commit —amend, так і через hg strip —keep).
* Імена гілок у hg вічні. Якщо планується якась експериментальна гілка, яку планується назвати «experimental», дуже бажано подумати ще раз, чи вартує їй давати саме таке ім’я, оскільки навіть з hg commit —close-branch створити нову гілку із таким іменем більше не можна буде. Ніколи. Навіть через два роки. Смішно, але тут навіть svn ліпше виглядає.
* Закладки (bookmarks), які концептуально трохи ближчі до git-ових гілок, в hg випиляти інколи також складно (якщо можливо).
* Субрепозиторії в hg мені особисто здаються «дикішими» за субмодулі в git, оскільки hg при коміті в батьківському репозиторії оновляє .hgsubstate, якщо, знову ж таки, в hg commit не вказати правильний фільтр.
* .hgignore лише, по ходу, в кореневій директорії. Якщо субдиректорії мігрують з місця на місце з часом, це також означає, що шляхи в одному .hgignore також потрібно поправити вручну.
Заметь, человек для себя предпочитает Hg, но его подобные грабли таки достали. Я до такой глубины ещё даже первично не докопался.
_>Ну и зря. Если лично тебе оно не нужно, то это не значит что и другим тоже. Я знаю многих использующих Mercurial вообще без named branches/bookmarks и при этом очень довольных удобством работы.
Это несекьюрно, годится только для персонального репо, который ни с кем не обменивается.
Лучше это было бы перенести в extensions и не включать по умолчанию.
_>Ох, ну я же ещё в самом начале этой дискуссии писал, что за годы параллельного развития все современные dcvs обрели приблизительно одинаковые технические возможности (ну вот разве что git так и не научился по нормальному анонимным веткам) и выбор должен делаться только по удобству (достаточно субъективная вещь) их использования. Ну если хочешь, можем разобрать по пунктам. )
Ну да, теперь осталось сделать совсем немного мелочей:
1. Внести такие действительно полезные вещи, как shelve, record, histedit, rebase в базовую функциональность, а не расширения.
2. Диверсии в виде неименованных голов, наоборот, вынести в расширения и не включать по умолчанию.
3. Описанным расширениям довести функциональность до минимально необходимого набора:
* показ staging, сброс staging в ноль, частичный сброс (по файлу, по диффу).
* shelve должен уметь брать не только локальные изменения, но и staging.
4. Решить остальные описанные Lyubomyr Shaydariv проблемы. Для начала, переименовать таки "ветки" во что-то другое (покопался в словаре, нашёл замечательное слово tally). Далее, обеспечить возможность их делать неуникальными (а лучше вообще не опираться на "закрытие", эта концепция должна умереть). Решить остальные описанные им проблемы.
_>В Mercurial это тоже реализовано, через команду hg histedit. Однако я крайне не рекомендую использовать этот подход, т.к. правильным методом review в DCVS должно быть создание новой ревизии.
Я проверил — histedit меняет хэш ревизии, так что тут, похоже, сделано адекватно (как в Git, Monotone и прочих, где хэш гарантированно требуется проверяемым по содержанию конкретной ревизии). А вот то, что ты этого не знаешь, и то, что я про histedit вытащил только после долгой дискуссии, показывает, что твой опыт просто неприменим под мои задачи и подходы.
_>Кстати, решение конфликтов — это должен был бы быть ещё отдельный пункт (ж — это же у тебя про экспорт/импорт). Но думаю там особых отличий нет, хотя алгоритмы и совсем разные. А вот что касается экспорт/импорта, то как раз тут у Mercurial всё намного проще и удобнее.
Опять пустые эмоциональные заклинания.
_>Тут и наличие анонимных веток и их поведение при синхронизации (они просто все возникают у всех)
Я уже говорил, что в Git ты можешь потребовать синхронизации полного пучка веток, но по умолчанию это отключили в 2.2.
_>Это от непривычки. ) А потом оказывается, что это ещё и намного удобнее старых подходов.
приводил картинку того, что имею в виду. Предположим что ревизии 2 и 3 созданы на разных компьютерах. Как бы ты реализовал подобное с помощью git? )
Очевидно — fetch+merge. Если ты хочешь сказать, что тебя утомляет необходимость назвать принятую от другого ветку, то я могу только выразить соболезнования, но не согласиться.
Здравствуйте, alex_public, Вы писали:
N>>А должно быть "передаём команде ярлык branch1", например. Но не ветку. Но этот твой пример ещё интереснее. Я приводил диаграмму, где этим тегом пометил два коммита в разных ветках. Что команда сделает? Если отфильтрует из всего репо или от указанной точки роста все такие коммиты, то ещё понятно, но какой смысл, если они могут не входить в DAG с общей головой? А если что-то сделать с потенциальной головой, то если их две, какое будет принято решение? _>Не, команды по определению имеющие дело с одной ревизией только их и принимают (а не имена ссылок/закладки/теги и т.п.).
А зачем тогда эти ярлыки используются? Только для чтения истории "под какой ярлык была эта ревизия"? Из пушки по воробьям.
_>>>Неизменность истории мне нравится больше) N>>А при чём тут вообще неизменность истории? _>Ну точнее речь не вообще об истории, а о сохранение расклада с именными ветками)
Так это же не именные ветки. Это произвольные ярлыки. Если ревизия зафиксирована, их менять нельзя. Сохраняй себе сколько угодно, но не зови их ветками.
_>>>А если причиной развилки будет всего лишь синхронизация изменений с двух разных машин? ) N>>Притянул состояние с другой машины — да, явно назвав, иначе несекьюрно — и начал играться. N>>А при многих таких нескольких — даже в пределах одного отдела — название ветки начинает играть роль собственно принципиального указания, от кого взято конкретное изменение, потому что понять это по содержанию уже невозможно. _>Так а зачем мне изменения другого отдела в чистом виде? ) Мне они не нужны. Мне нужна основная ветка развития, с применёнными к ней изменениями этого отдела (потому как кто кроме них правильнее осуществит слияние их изменений).
Тогда у неё будет постоянное имя. С другой стороны, представь себе вариант, когда все слияния делает менеджер (мы рассматривали такое как вариант, правда, на базе Gerrit, а не локальных репо).
N>>Безымянная ветка для этого становится случаем ничтожной экономии усилий на частный случай, когда таких источников считанные единицы, они не конфликтуют (до неразличения) по смыслу с любыми локальными изменениями (а программист ещё не устал и способен отличать источники по их виду), используемые средства явно показывают все эти головы и их не настолько много, чтобы не вмещались в интерфейс... возможно, ты и твоя команда способны всё это осиливать, но я предпочту тратить мысленные усилия на что-то более для меня полезное.
_>Какие мысленные усилия? ) Если предположим (для упрощения объяснения) в данной разработке не нужны долгоживущие отдельные ветки (которые по смыслу создаются, а не для синхронизации отдельных членов команды), то в Mercurial будет просто ровно одна ветка периодически разветвляющаяся (в моменты параллельной разработки членов команды) и тут же сливающаяся в одну.
_>А что будет в случае в Git? )
Здравствуйте, alex_public, Вы писали:
_>>>Эм, а какой смысл имеет последовательная группа ревизий с меткой "release"? ) Release — это же обычно некий фиксированный момент времени, а не интервал. Соответственно в репозитории это соответствует одной выделенной ревизии. Обычно её или помечают соответствующим тегом прямо в основной ветке или же создают отдельную ветку с именем release, в которую изредка (как раз в моменты времени релиза) сливают результаты из основной ветки. А то, что показал ты, я никогда не видел и пока не могу представить для чего оно может понадобиться. _>·>Да, смысла меток на ревизиях нет, поэтому подход hg и является не самым осмысленным. _>Какой ещё подход hg? ) Это же ты предлагаешь такую схему. )))
Прошу прощения, не так понял. Я подумал, что под меткой ты понимаешь отметку каждой ревизии именем бранча.
_>·>Ладно. Давай заменим "release" на "release_candidate", чтобы тебе понятнее было. Т.е. мы хотим знать какую ревизию мы сейчас тестируем более тяжелыми тестами (ручное или soak тестирование, например). _>Так, давай разберёмся подробно что же ты собственно хочешь. Эти метки должны изменяться со временем или нет? Метка должна быть на одной ревизии или на последовательном их наборе? Ветвление (реальное) требуется или нет? )
Да. Если кто-то что-то коммитит/мержит в development, метка "development" должна указывать на последние изменения. То же верно и для release.
_>·>А тегом помечаются конкретные номера публичных версий, и теги — read-only. _>Ну так это смотря где))) В Mercurial они вполне редактируемы. )
Мрак. Фтопку.
_>>>Нельзя) Но у тебя же там как раз последовательность фиксаций нарисована. ) _>·>Что за фиксации? Ревизии в смысле? Ревизия это коммит, т.е. патч+автор+етс. _>Что-то у тебя проблемы не только с пониманием документации Mercurial, но и вообще с переводом английского текста на русский. Commit — это действие (глагол), переводим как фиксация. А changeset — это объект (существительное), переводим как ревизия. Ну а слова "коммит" в русском языке нет и уж тем более в виде существительного (если уж и использовать подобный англицизм, то он должен быть глаголом).
Хз, я плохо разбираюсь в русской терминологии.
В документации git слово commit используется и как существительное. Например: "After you have created several commits, or if you have cloned a repository with an existing commit history".
_>·>Создание ветки это только в hg является коммитом, что опять фигня какая-то. _>Только наоборот. Фиксация ревизии порождает ветвление (при условие наличие у текущей ревизии другого потомка) и это абсолютно логично.
Разве можно создать именованный бранч без коммита в hg? Т.е. была у тебя ветка development, ты создаёшь на её основе release_branch — нужно делать коммит? Если да, появится ли diverging point?
_>>>Ну например по автору и по предку (в GUI по положения в дереве). _>·>"автор" не годится. Я могу продолжить твой эксперимент и накоммитить туда что-нибудь, и даже обратно тебе потом запушить. _>·>"предок" уж тем более не годится, т.к. мы можем начать свои эксперименты от одной и той же ревизии, скажем, последнего публичного релиза. _>Скорее всего так и будет. Но при этом в визуальном дереве всё будет чётко видно и отделено. )
Как я понимаю, это будут "две головы одной именованной ветки" и это видно, но т.к. головы анонимны, как их различать? "Хочу поработать над своим экспериментом, делаю git checkout experiment, хочу поработать над твоим, делаю git checkout alex_public_experiment". Что делать в hg?
_>>>Я так и не понял, зачем ты хочешь применять ветки там, где нет развилок? ) _>·>Не "нет развилок", а может не быть развилок. Даже hg это упоминает: "A new branch name can be started in the middle of a development line, not necessarily at a diverging point". Но начало именованного бранча это уже коммит, а поэтому история уже разъедется. Бардак жуткий. _>Я вообще то и не говорил, что это в Mercurial невозможно (более того, выше я упоминал, что это реализуется даже меньшим числом команд, чем в git). Я спрашиваю про другое — зачем может понадобится подобная бредовая конструкция? )
Это одно из основных применений веток — отмечать какие-то разные стадии разработки.
_>>>·>Или, иначе говоря, выразить тот факт, что мы зарелизили всё что надевелопили. _>>>Ну поставь на последнюю ревизию тег "release 2.0" и всё. Или же организуй отдельную ветку с релизами. Я уже писал выше. _>·>Теги для конкретных версий, а не для процесса релиза. _>Понятие "процесс релиза" в контексте систем контроля версий по прежнему остаётся для меня загадкой. )))
Не понял. В релиз выпускаются версии несколько другие, чем сейчас в разработке, а ещё есть багфиксы, релиз-кандидаты, бета-релизы, публичные, внутренние, етс. Это всё является частью процесса релиза. И это нужно как-то контролировать.
_>·>Ок, если не отличается, значит одно можно заменить на другое, смысл меняться не должен. Давай попробуем. Возьмём _>·>"Branches occur if lines of development diverge" _>·>заменяем _>·>"Branches occur if branches diverge" _>·>Теперь объясни смысл этого предложения. _>Ветвления происходят при разделение веток. )
Масло маслянное. Ты более менее формальное определение можешь сказать? И почему ты избегаешь ответа на "Плиз, на моём графе отметь все эти понятия"?
_>>>·>Бранч может иметь несколько их. В этом и путаница, которая требует новой сущности. В гите этот термин бессмысленен. _>>>Не может. ) Несколько голов может иметь виртуальная (потому как в реальности её не существует, а есть несколько веток с одинаковым атрибутом "имя") сущность называемая named branch. _>·>Почему тогда без этой виртуальной сущности hg, как ты говоришь, не сможет функционировать? _>Ээээ что? ) Я как раз наоборот всё время говорю, что mercurial можно удобно пользоваться вообще без затрагивания "имён для веток"/закладок/тегов, работая только с чистыми базовыми ветвлениями (естественно анонимными) на основе ревизий. Т.е. в основе лежит именно это, а поверх накручены дополнительные опциональные удобства (имена для веток/закладки/теги).
Я тогда не понимаю, почему ты не можешь сказать определение этих базового понятия?
Вот в git есть три основных понятия — snapshot, dag и reference. Всё. Остальное — накручено для удобства.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, netch80, Вы писали: N>* Якщо планується якась експериментальна гілка, яку планується назвати «experimental», дуже бажано подумати ще раз, чи вартує їй давати саме таке ім’я, оскільки навіть з hg commit —close-branch створити нову гілку із таким іменем більше не можна буде. Ніколи. Навіть через два роки.
Брешет. Я не спец в hg (использую для домашних проектов), в git так вообще ноль, поэтому в дискуссию не лезу, но то что он описывает, я проделывал раз сто.
Здравствуйте, alexzz, Вы писали:
A>Здравствуйте, netch80, Вы писали:
N>>* Якщо планується якась експериментальна гілка, яку планується назвати «experimental», дуже бажано подумати ще раз, чи вартує їй давати саме таке ім’я, оскільки навіть з hg commit —close-branch створити нову гілку із таким іменем більше не можна буде. Ніколи. Навіть через два роки. A>Брешет. Я не спец в hg (использую для домашних проектов), в git так вообще ноль, поэтому в дискуссию не лезу, но то что он описывает, я проделывал раз сто.
Я склонен верить обеим сторонам Тогда остаётся понять, в чём же разница в условиях.
Здравствуйте, netch80, Вы писали:
N>Я склонен верить обеим сторонам Тогда остаётся понять, в чём же разница в условиях.
Сам попробуй. Проверил как мог:
Здравствуйте, alexzz, Вы писали:
A>Здравствуйте, netch80, Вы писали:
N>>Я склонен верить обеим сторонам Тогда остаётся понять, в чём же разница в условиях. A>Сам попробуй. Проверил как мог:
Видел. Не хочу. Всё равно я эту чушь с "permanent branches" не буду использовать, разве что начальство скажет, но это тогда их проблема научить отсутствию конфликтов Пока что вокруг меня Git и нет тенденции этому меняться. Так что среди всех описанных проблем это чуть ли не наименее важная.
Здравствуйте, ·, Вы писали:
·>Как я понимаю, это будут "две головы одной именованной ветки" и это видно, но т.к. головы анонимны, как их различать? "Хочу поработать над своим экспериментом, делаю git checkout experiment, хочу поработать над твоим, делаю git checkout alex_public_experiment". Что делать в hg?
Вот три анонимные ветви. Одна, допустим, твоя, а две другие прилетели от других пользователей. Не понимаю проблему.
N>Всё равно я эту чушь с "permanent branches" не буду использовать,
Если имеется в виду, что после слияния ветки, например, experimental с default команда hg branches продолжает показывать оба названия, то закрываешь experimental, если пока больше не нужна, и она перестаёт отсвечивать в списке. Закрытие, по-моему, ни на что больше не влияет и никаких ограничений не накладывает.
Здравствуйте, netch80, Вы писали:
_>>Ну как видишь никаких ограничений нет на самом деле (и я кстати об этом говорил изначально). Есть только разница в удобстве (причём в пользу Mercurial). Люди даже подобные https://www.mercurial-scm.org/wiki/GitConcepts#Command_equivalence_table таблички соответствия команд делают. ))) Но опять же там есть не все команды (например нет heads) из-за отсутствия в конкуренте соответствующей концепции (типа анонимных веток). N>Вот тут на родственном форуме (если ты в РФ, то без Tor не прочтёшь) коллега Lyubomyr Shaydariv пишет (месяца 3 назад, так что актуально):
Трудно читать на украинском) Хотя смысл угадывается конечно. )))
N>... N>Заметь, человек для себя предпочитает Hg, но его подобные грабли таки достали. Я до такой глубины ещё даже первично не докопался.
Из существенных претензий тут только пункт с close-branch. Если бы он был правдивый (тут уже вроде всё показали на эту тему).
_>>Ну и зря. Если лично тебе оно не нужно, то это не значит что и другим тоже. Я знаю многих использующих Mercurial вообще без named branches/bookmarks и при этом очень довольных удобством работы. N>Это несекьюрно, годится только для персонального репо, который ни с кем не обменивается. N>Лучше это было бы перенести в extensions и не включать по умолчанию.
Как раз использовали для совместной работы. Правда небольшими командами (в крупных и формализованных командах всё же уже требуются именованные разделители какого-то вида). Очень удобно.
_>>Ох, ну я же ещё в самом начале этой дискуссии писал, что за годы параллельного развития все современные dcvs обрели приблизительно одинаковые технические возможности (ну вот разве что git так и не научился по нормальному анонимным веткам) и выбор должен делаться только по удобству (достаточно субъективная вещь) их использования. Ну если хочешь, можем разобрать по пунктам. ) N>Ну да, теперь осталось сделать совсем немного мелочей: N>1. Внести такие действительно полезные вещи, как shelve, record, histedit, rebase в базовую функциональность, а не расширения.
А чем по твоему отличаются расширения входящие в поставку Mercurial от обычных команд? ) Лично я не вижу вообще никакой разницы.
N>2. Диверсии в виде неименованных голов, наоборот, вынести в расширения и не включать по умолчанию.
Как ты себе представляешь отключение по умолчанию базовой функциональности, вокруг которой и строится вся система? )))
N>3. Описанным расширениям довести функциональность до минимально необходимого набора: N>* показ staging, сброс staging в ноль, частичный сброс (по файлу, по диффу). N>* shelve должен уметь брать не только локальные изменения, но и staging.
Возможно допилят (я же говорю, что технические возможности систем сходятся постепенно). Хотя лично я и все мои окружающие вообще не пользуются командой record, даже в таком виде. Собственно большинство вообще из IDE работает, где это всё неактуально.
N>4. Решить остальные описанные Lyubomyr Shaydariv проблемы. Для начала, переименовать таки "ветки" во что-то другое (покопался в словаре, нашёл замечательное слово tally). Далее, обеспечить возможность их делать неуникальными (а лучше вообще не опираться на "закрытие", эта концепция должна умереть). Решить остальные описанные им проблемы.
Это вроде уже обсудили. )
_>>В Mercurial это тоже реализовано, через команду hg histedit. Однако я крайне не рекомендую использовать этот подход, т.к. правильным методом review в DCVS должно быть создание новой ревизии. N>Я проверил — histedit меняет хэш ревизии, так что тут, похоже, сделано адекватно (как в Git, Monotone и прочих, где хэш гарантированно требуется проверяемым по содержанию конкретной ревизии). А вот то, что ты этого не знаешь, и то, что я про histedit вытащил только после долгой дискуссии, показывает, что твой опыт просто неприменим под мои задачи и подходы.
Причём тут изменение хэша ревизии? ) Я вообще про другое говорил. Что предпочитаю подход в котором всё, что попадает в систему контроля версий, уже навсегда остаётся в истории. Поэтому мне и имена веток в Mercurial больше нравятся и команды типа histedit я не использую в принципе.
Да, кстати, а вот тебе похоже должен был бы понравиться этот https://www.mercurial-scm.org/wiki/MqTutorial инструмент. Он кстати пока входит в поставку, но обсуждается вопрос его удаления... )))
_>>Тут и наличие анонимных веток и их поведение при синхронизации (они просто все возникают у всех) N>Я уже говорил, что в Git ты можешь потребовать синхронизации полного пучка веток, но по умолчанию это отключили в 2.2.
Я не об этом (тут понятно что всего лишь опция команды), а про то, как чужие ветки выглядят в твоём репозитории. )
_>>Я вот здесь http://rsdn.ru/forum/flame.comp/6338865.1
приводил картинку того, что имею в виду. Предположим что ревизии 2 и 3 созданы на разных компьютерах. Как бы ты реализовал подобное с помощью git? ) N>Очевидно — fetch+merge. Если ты хочешь сказать, что тебя утомляет необходимость назвать принятую от другого ветку, то я могу только выразить соболезнования, но не согласиться.
Нуу покажи пример. Что бы git log --graph показал картинку аналогичную той моей (причём в каждом из двух репозиториев). И при этом прикинуть объём команд необходимый для этого. Могу сделать аналогичное для mercurial. )
Здравствуйте, alexzz, Вы писали:
A>·>Как я понимаю, это будут "две головы одной именованной ветки" и это видно, но т.к. головы анонимны, как их различать? "Хочу поработать над своим экспериментом, делаю git checkout experiment, хочу поработать над твоим, делаю git checkout alex_public_experiment". Что делать в hg? A>Вот три анонимные ветви. Одна, допустим, твоя, а две другие прилетели от других пользователей. Не понимаю проблему. A>Image: hg3.png
Проблема — различить эти анонимные ветки: что от кого прилетело, как узнать на какую из них переключится, как что-то там поменять и запушить обратно, туда, откуда прилетело.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, netch80, Вы писали:
_>>Не, команды по определению имеющие дело с одной ревизией только их и принимают (а не имена ссылок/закладки/теги и т.п.). N>А зачем тогда эти ярлыки используются? Только для чтения истории "под какой ярлык была эта ревизия"? Из пушки по воробьям.
Так есть же множество команд работающих с наборами ревизий) Там и push/pull/bundle/clone и incoming/outgoing и log и т.д. и т.п.
_>>Так а зачем мне изменения другого отдела в чистом виде? ) Мне они не нужны. Мне нужна основная ветка развития, с применёнными к ней изменениями этого отдела (потому как кто кроме них правильнее осуществит слияние их изменений). N>Тогда у неё будет постоянное имя. С другой стороны, представь себе вариант, когда все слияния делает менеджер (мы рассматривали такое как вариант, правда, на базе Gerrit, а не локальных репо).
Т.е. чтобы сделать аналог простейшего режима работы в Mercurial вообще без именованных веток в Git надо завести в каждом репозитории минимум 2 ветки (одну общую для синхронизации и слияний и одну для локальной разработки), правильно? )
_>>Какие мысленные усилия? ) Если предположим (для упрощения объяснения) в данной разработке не нужны долгоживущие отдельные ветки (которые по смыслу создаются, а не для синхронизации отдельных членов команды), то в Mercurial будет просто ровно одна ветка периодически разветвляющаяся (в моменты параллельной разработки членов команды) и тут же сливающаяся в одну. _>>А что будет в случае в Git? ) N>То же самое.
Ну покажи пример такого графа. )
P.S. Кстати, тут что-то вспомнилось... А что у git с аналогами команд hg copy/rename/remove? ) Помнится он там что-то автоматическое пытался делать, но чаще всего криво... )))
Здравствуйте, ·, Вы писали:
A>>Вот три анонимные ветви. Одна, допустим, твоя, а две другие прилетели от других пользователей. Не понимаю проблему. A>>Image: hg3.png ·>Проблема — различить эти анонимные ветки: что от кого прилетело, как узнать на какую из них переключится, как что-то там поменять и запушить обратно, туда, откуда прилетело.
У каждого коммита написано, кто его автор. Прилетело оттуда, откуда сделал к себе pull. Туда же и пушить.
Репозиторий Маши:
0 — установочный коммит
1 — Маша сделала pull, закоммитила, сделала push
2 — Маша закоммитила ещё и снова сделала push.
Потом она решила посмотреть, как там дела у остальных и сделала pull. Увидела, что Петя тоже кое-что закоммитил:
3 — Изменения, пришедшие от Пети
4 — Маша решила Пете помочь, сделала изменения в его ветке, закоммитила, запушила.
5 — Потом Маша вернулась к своей задаче, вечером закоммитила в свою ветку, сделала push и ушла домой.
Репозиторий Пети:
0 — установочный коммит
1 — Петя сделал pull и увидел коммит от Маши.
2 — Взяв его за основу, Петя кое-то добавил, закоммитил, сделал push и пошёл пить чай до вечера.
3 — Вернувшить, Петя закоммитил ещё и решил посмотреть, что Маша успела наделать за день — pull.
4
5 — Петя увидел, что Маша внесла некоторые изменения в Петину фичу
6
7 — Петя влил Машины изменения к себе, закоммитил, запушил и тоже пошёл домой.
Центральный репозиторий на bitbucket.org, с которым Маша с Петей синхронизируются, выглядит теперь как-то так:
Маша и Петя спокойно обошлись без именованных веток, без bookmarks, без тэгов, вообще без всего.
Здравствуйте, ·, Вы писали:
_>>·>Да, смысла меток на ревизиях нет, поэтому подход hg и является не самым осмысленным. _>>Какой ещё подход hg? ) Это же ты предлагаешь такую схему. ))) ·>Прошу прощения, не так понял. Я подумал, что под меткой ты понимаешь отметку каждой ревизии именем бранча.
Я на самом деле просто не понял твою задачу и соответственно не мог сказать какой именно из сервисных инструментов (работающих поверх базовой функциональности анонимных веток) mercurial надо использовать в твоём случае:
1. имя ветки — неизменяемый атрибут (т.е. применим ко многим ревизиям) ревизии с особым свойством (автоматически наследуется потомками, если пользователем не указано иного при фиксации)
2. закладка — указатель (т.е. применим только к одной ревизии) с особым свойством (автоматически перескакивает на следующую ревизию при фиксации)
3. тег — указатель, свободно меняемый пользователем
_>>Так, давай разберёмся подробно что же ты собственно хочешь. Эти метки должны изменяться со временем или нет? Метка должна быть на одной ревизии или на последовательном их наборе? Ветвление (реальное) требуется или нет? ) ·>Да. Если кто-то что-то коммитит/мержит в development, метка "development" должна указывать на последние изменения. То же верно и для release.
Ну так значит под случай похоже оптимальнее всего подходят закладки из mercurial.
_>>·>А тегом помечаются конкретные номера публичных версий, и теги — read-only. _>>Ну так это смотря где))) В Mercurial они вполне редактируемы. ) ·>Мрак. Фтопку.
Ммм, завидно? )))
_>>Что-то у тебя проблемы не только с пониманием документации Mercurial, но и вообще с переводом английского текста на русский. Commit — это действие (глагол), переводим как фиксация. А changeset — это объект (существительное), переводим как ревизия. Ну а слова "коммит" в русском языке нет и уж тем более в виде существительного (если уж и использовать подобный англицизм, то он должен быть глаголом). ·>Хз, я плохо разбираюсь в русской терминологии. ·>В документации git слово commit используется и как существительное. Например: "After you have created several commits, or if you have cloned a repository with an existing commit history".
Ну собственно "фиксация" — это и есть существительное. ) Это я выше некорректно написал (там было правильнее написать "фиксировать"). Только его значение является совсем не синонимом слову ревизия, а обозначает событие. )
_>>Только наоборот. Фиксация ревизии порождает ветвление (при условие наличие у текущей ревизии другого потомка) и это абсолютно логично. ·>Разве можно создать именованный бранч без коммита в hg? Т.е. была у тебя ветка development, ты создаёшь на её основе release_branch — нужно делать коммит? Если да, появится ли diverging point?
Нельзя) Нет, ветвления не появится пока не породишь ещё одного потомка из этой точки (не важно с каким именем). А пока у тебя вышло просто переименование одной и той же ветки. )
_>>Скорее всего так и будет. Но при этом в визуальном дереве всё будет чётко видно и отделено. ) ·>Как я понимаю, это будут "две головы одной именованной ветки" и это видно, но т.к. головы анонимны, как их различать? "Хочу поработать над своим экспериментом, делаю git checkout experiment, хочу поработать над твоим, делаю git checkout alex_public_experiment". Что делать в hg?
Так в Mercurial checkout (он же update) работает с именем ревизии и это является как раз привычным путём в любом случае. Правда туда можно передавать различные "хоткеи" (именованные ветки — тогда подразумевается их tip, закладки, теги), но это уже добавлено поверх, для удобства.
_>>Я вообще то и не говорил, что это в Mercurial невозможно (более того, выше я упоминал, что это реализуется даже меньшим числом команд, чем в git). Я спрашиваю про другое — зачем может понадобится подобная бредовая конструкция? ) ·>Это одно из основных применений веток — отмечать какие-то разные стадии разработки.
Первый раз про такое слышу. Использовать ветки для ситуации без ветвления. Это похоже только от убогости других инструментов git'a.
_>>Понятие "процесс релиза" в контексте систем контроля версий по прежнему остаётся для меня загадкой. ))) ·>Не понял. В релиз выпускаются версии несколько другие, чем сейчас в разработке, а ещё есть багфиксы, релиз-кандидаты, бета-релизы, публичные, внутренние, етс. Это всё является частью процесса релиза. И это нужно как-то контролировать.
Вот всё, что ты перечислил, можно применить к какой-то отдельной ревизии (соответственно для этого оптимальные теги). А вот куда применить понятие "процесс релиза" не ясно. )
_>>·>Теперь объясни смысл этого предложения. _>>Ветвления происходят при разделение веток. ) ·>Масло маслянное. Ты более менее формальное определение можешь сказать? И почему ты избегаешь ответа на "Плиз, на моём графе отметь все эти понятия"?
Формальное определение я тебе показывал не раз и даже цитировал пару сообщений назад. ) По поводу твоего графа я не понял что собственно на нём нарисовано. Там есть последовательность ревизий без ветвлений (это понятно). И пара каких-то меток, причём в одной точке (что это собственно не понятно, по идее похоже на теги или закладки, раз применены к одной ревизии).
_>>Ээээ что? ) Я как раз наоборот всё время говорю, что mercurial можно удобно пользоваться вообще без затрагивания "имён для веток"/закладок/тегов, работая только с чистыми базовыми ветвлениями (естественно анонимными) на основе ревизий. Т.е. в основе лежит именно это, а поверх накручены дополнительные опциональные удобства (имена для веток/закладки/теги). ·>Я тогда не понимаю, почему ты не можешь сказать определение этих базового понятия? ·>Вот в git есть три основных понятия — snapshot, dag и reference. Всё. Остальное — накручено для удобства.
А вообще, если кратко, то главной сущностью является граф ревизий (changeset'ов, у каждого уникальный id), связанный отношениями потомок/предок. И собственно всё. В Git на самом деле внутри тоже самое. Единственная разница в том, что в Git нет адекватных инструментов для удобной работы с этим базисом — требуется введение дополнительных сущностей более высокого уровня (типа указателей на ветки, специальных команд для ветвления и т.п.). А в Mercurial есть удобные инструменты для работы на этом уровне и соответственно это и является основным режимом работы, а всякие там дополнительные удобства (имена веток, закладки, теги) являются лишь опциональной надстройкой над этим.
Здравствуйте, alexzz, Вы писали:
A>>>Вот три анонимные ветви. Одна, допустим, твоя, а две другие прилетели от других пользователей. Не понимаю проблему. A>>>Image: hg3.png A>·>Проблема — различить эти анонимные ветки: что от кого прилетело, как узнать на какую из них переключится, как что-то там поменять и запушить обратно, туда, откуда прилетело. A>У каждого коммита написано, кто его автор. Прилетело оттуда, откуда сделал к себе pull. Туда же и пушить.
Автор может быть один и тот же. Представь один репо на моём ноуте, второй — на моём десктопе. Т.е. по автору отличить можно далеко не всегда.
A>Репозиторий Маши: A>Image: hg4.PNG
Даже в случае разных авторов — в этом репозитории уже сложно отличить ревизии 4 и 5 — оба имеют автором Машу, нужно смотреть историю глубже, разбираться с коммит-сообщениями... а в общем случае, когда Маша и Петя меняют что попало где попало — в каждой из голов может быть полная мешанина авторов. Т.е. автор это не точное отличие, а империческое — обычно работает, но иногда подводит.
A>Маша и Петя спокойно обошлись без именованных веток, без bookmarks, без тэгов, вообще без всего.
Собственно в git будет та же история, но не будет путаницы. Т.к. при совпадении имён веток, Маша может вытянуть ветку Пети под другим именем, скажем, назвать её в своём репозитории как petya_dev. По смыслу — ветки dev у Пети и у Маши — независимые истории. Почему их нужно насильно сталкивать лишь по тому, что у них случайно совпали имена — хз.
Ну и ещё отличие — графы истории во всех репозиториях будут выглядеть эквивалентно, не будет путаницы с совпадающими номерами ревизий.
A>5 — Петя увидел, что Маша внесла некоторые изменения в Петину фичу A>6 A>7 — Петя влил Машины изменения к себе, закоммитил, запушил и тоже пошёл домой.
Кстати, интересно. Как Петя может посмотреть Машины изменения перед вливанием? Я правильно понимаю, что у него уже будет три безымянные головы?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
A>>Маша и Петя спокойно обошлись без именованных веток, без bookmarks, без тэгов, вообще без всего. ·>Собственно в git будет та же история, но не будет путаницы. Т.к. при совпадении имён веток, Маша может вытянуть ветку Пети под другим именем, скажем, назвать её в своём репозитории как petya_dev. По смыслу — ветки dev у Пети и у Маши — независимые истории.
Если Маша и Петя станут путаться, они могут начать использовать и локальные закладки, и синхронизируемые закладки, и именованные ветки. Например, в самом простом варианте, Маша может пометить локальной закладкой свою головную ревизию и легко отличать её от всех остальных головных ревизий, если таковые возникнут; а Петя может ничего не делать, если его всё устраивает. Или они могут каждый сделать себе по закладке и сказать синхронизировать их между репозиториями. Могут под свои задачи именованные ветки завести, если захотят или потребуется зачем-то.
·> Почему их нужно насильно сталкивать лишь по тому, что у них случайно совпали имена — хз.
Я думаю, слово "нужно" неверно. Устраивает базовый функционал анонимных веток? Пользуешься им. Испытываешь неудобства? Можешь использовать закладки и/или именованные ветки.
A>>5 — Петя увидел, что Маша внесла некоторые изменения в Петину фичу A>>6 A>>7 — Петя влил Машины изменения к себе, закоммитил, запушил и тоже пошёл домой. ·>Кстати, интересно. Как Петя может посмотреть Машины изменения перед вливанием? Я правильно понимаю, что у него уже будет три безымянные головы?
Я слово «влил» использовал не подумав, имея в виду merge Петей изменений, которые Маша сделала в Петину ветку. В результате не очень понимаю, о чём ты спрашиваешь. После того как Петя пришёл вечером, сделал коммит и выполнил pull, он действительно увидит три головные ревизии. Одна Машина, другая Петина, третья тоже Петина, но созданная Машей. Как он поймёт, что Маша что-то сделала в его ветке?
Если использовать только неименованные ветки, то просто увидит, что из одной из ревизий, над которыми он работал, выросла новая голова.
Если он знает, что ему так будет неудобно, он может озаботиться, например, использованием синхронизируемых закладок. Тогда он тоже увидит три головные ревизии, но они будут подписаны:
1. Petya's stuff — последняя ревизия, над которой работал Петя.
2. Petya's stuff@default — нечто, некогда отпочковавшееся от Петиной ветки и вернувшееся обратно со стороны, из удалённого репозитория, с которым Петя синхронизировался, и который у него в настройках назван default. Это локальная закладка, видимая только Пете. Он может её оставить, переименовать или удалить, если хочет.
3. Головная ревизия без закладки — от ветки, которую ведёт Маша. Она знает, что Петя к ней не полезет и не стала делать закладку для своей ветки. (На самом деле мне лень редактировать репозитории).
После слияния двух Петиных веток, коммита и пуша финальный результат выглядит так:
Репозиторий Маши (она ушла раньше, и у неё не хватает последних изменений):
Здравствуйте, alex_public, Вы писали:
_>>>Так, давай разберёмся подробно что же ты собственно хочешь. Эти метки должны изменяться со временем или нет? Метка должна быть на одной ревизии или на последовательном их наборе? Ветвление (реальное) требуется или нет? ) _>·>Да. Если кто-то что-то коммитит/мержит в development, метка "development" должна указывать на последние изменения. То же верно и для release. _>Ну так значит под случай похоже оптимальнее всего подходят закладки из mercurial.
Собственно да, букмарки и создавались по образу и подобию веток гита. Но проблемы с ними есть. Скажем, управлять нельзя как они пуллятся. И опять — глобальные имена "Be aware that there is only one namespace for bookmarks — it is advised to prefix your local-only bookmarks to avoid conflicts with other users."
И т.к. это опциональная фича с боку... как они поддерживаются другими тулзами? CI сервера, IDE, и т.п.?
_>>>·>А тегом помечаются конкретные номера публичных версий, и теги — read-only. _>>>Ну так это смотря где))) В Mercurial они вполне редактируемы. ) _>·>Мрак. Фтопку. _>Ммм, завидно? )))
В git их тоже можно редактировать (ибо это принципиально невозможно запретить в распределённой системе), но git при этом громко орёт и матерится: "Ты чЁ?! С дубу рухнул?! Справку от психиатра предъяви, ламьё!!!".
_>·>Хз, я плохо разбираюсь в русской терминологии. _>·>В документации git слово commit используется и как существительное. Например: "After you have created several commits, or if you have cloned a repository with an existing commit history". _>Ну собственно "фиксация" — это и есть существительное. ) Это я выше некорректно написал (там было правильнее написать "фиксировать"). Только его значение является совсем не синонимом слову ревизия, а обозначает событие. )
Брр. Бардак, ибо lingvo говорит, что commit это глагол только.
_>>>Только наоборот. Фиксация ревизии порождает ветвление (при условие наличие у текущей ревизии другого потомка) и это абсолютно логично. _>·>Разве можно создать именованный бранч без коммита в hg? Т.е. была у тебя ветка development, ты создаёшь на её основе release_branch — нужно делать коммит? Если да, появится ли diverging point? _>Нельзя) Нет, ветвления не появится пока не породишь ещё одного потомка из этой точки (не важно с каким именем). А пока у тебя вышло просто переименование одной и той же ветки. )
Будет ревизия, с новым уникальным id, так ведь? Значит уже история пошла врозь.
И что сбивает с толку, есть коммит, с датой, с автором... но никаких изменений, diff пустой!
_>>>Скорее всего так и будет. Но при этом в визуальном дереве всё будет чётко видно и отделено. ) _>·>Как я понимаю, это будут "две головы одной именованной ветки" и это видно, но т.к. головы анонимны, как их различать? "Хочу поработать над своим экспериментом, делаю git checkout experiment, хочу поработать над твоим, делаю git checkout alex_public_experiment". Что делать в hg? _>Так в Mercurial checkout (он же update) работает с именем ревизии и это является как раз привычным путём в любом случае. Правда туда можно передавать различные "хоткеи" (именованные ветки — тогда подразумевается их tip, закладки, теги), но это уже добавлено поверх, для удобства.
В git тоже, всё так же. Правда работать с номерами ревизий — не гуманно, git освобождает от этой необходимости когда возможно. Все эти ветки, теги, символические ссылки и т.п. — чисто для удобства человеков, сам гит может обходиться исключительно sha1 (и это удобно, особенно когда пишешь какую-нибудь автоматизацию/скрипты/славароботам).
_>>>Я вообще то и не говорил, что это в Mercurial невозможно (более того, выше я упоминал, что это реализуется даже меньшим числом команд, чем в git). Я спрашиваю про другое — зачем может понадобится подобная бредовая конструкция? ) _>·>Это одно из основных применений веток — отмечать какие-то разные стадии разработки. _>Первый раз про такое слышу. Использовать ветки для ситуации без ветвления. Это похоже только от убогости других инструментов git'a.
Ещё раз. Оно расходится _может_, но не обязательно что _будет_. Скажем, если мы зарелизили что-то и оно всё сразу суперски заработало с первого раза — релиз будет в точности равен тому что надевелопилось. А если мы сделали поверх релиза хотфикс(ы) — ветки разойдутся.
_>>>Понятие "процесс релиза" в контексте систем контроля версий по прежнему остаётся для меня загадкой. ))) _>·>Не понял. В релиз выпускаются версии несколько другие, чем сейчас в разработке, а ещё есть багфиксы, релиз-кандидаты, бета-релизы, публичные, внутренние, етс. Это всё является частью процесса релиза. И это нужно как-то контролировать. _>Вот всё, что ты перечислил, можно применить к какой-то отдельной ревизии (соответственно для этого оптимальные теги). А вот куда применить понятие "процесс релиза" не ясно. )
Эээ. Если эти теги работают так же (можно, например, туда хотфикс закоммитиь) и мержить туды-сюды... то наверное сгодятся.
Т.е. я пушу что-нибудь в "release", это подхватывает CI-сервер, билдит, запускает тесты, шлёт имейлы, строит release notes, etc...
_>>>·>Теперь объясни смысл этого предложения. _>>>Ветвления происходят при разделение веток. ) _>·>Масло маслянное. Ты более менее формальное определение можешь сказать? И почему ты избегаешь ответа на "Плиз, на моём графе отметь все эти понятия"? _>Формальное определение я тебе показывал не раз и даже цитировал пару сообщений назад. ) По поводу твоего графа я не понял что собственно на нём нарисовано. Там есть последовательность ревизий без ветвлений (это понятно). И пара каких-то меток, причём в одной точке (что это собственно не понятно, по идее похоже на теги или закладки, раз применены к одной ревизии).
Пусть другой граф, пороще, с расхождением, мержем и одной веткой:
_>>>Ээээ что? ) Я как раз наоборот всё время говорю, что mercurial можно удобно пользоваться вообще без затрагивания "имён для веток"/закладок/тегов, работая только с чистыми базовыми ветвлениями (естественно анонимными) на основе ревизий. Т.е. в основе лежит именно это, а поверх накручены дополнительные опциональные удобства (имена для веток/закладки/теги). _>·>Я тогда не понимаю, почему ты не можешь сказать определение этих базового понятия? _>·>Вот в git есть три основных понятия — snapshot, dag и reference. Всё. Остальное — накручено для удобства. _>Вообще то я уже показывал все определения и ссылками и цитатами. Ну можешь глянуть ещё здесь https://www.mercurial-scm.org/wiki/UnderstandingMercurial — подробное объяснение с примерами. _>А вообще, если кратко, то главной сущностью является граф ревизий (changeset'ов, у каждого уникальный id), связанный отношениями потомок/предок. И собственно всё. В Git на самом деле внутри тоже самое.
dag т.е.
_>Единственная разница в том, что в Git нет адекватных инструментов для удобной работы с этим базисом — требуется введение дополнительных сущностей более высокого уровня (типа указателей на ветки, специальных команд для ветвления и т.п.).
Что ещё за указатели на ветки? Есть просто reference (ссылка) и всё. Сссылка с префиксом refs/heads/ является веткой, с префиксом refs/tags/ — тегом, с префиксом refs/remotes/ — ссылки из чужих репо, и т.п. Там же и stash, там же и notes и кастомные вещи, типа pull requests гитхаба.
Команды какие ещё? update-ref только, остальные (branch, tag, notes) просто надстройки — для удобства человеков только.
_>А в Mercurial есть удобные инструменты для работы на этом уровне и соответственно это и является основным режимом работы, а всякие там дополнительные удобства (имена веток, закладки, теги) являются лишь опциональной надстройкой над этим.
И все эти штуки — совершенно разные сущности.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, alexzz, Вы писали:
A>>>Маша и Петя спокойно обошлись без именованных веток, без bookmarks, без тэгов, вообще без всего. A>·>Собственно в git будет та же история, но не будет путаницы. Т.к. при совпадении имён веток, Маша может вытянуть ветку Пети под другим именем, скажем, назвать её в своём репозитории как petya_dev. По смыслу — ветки dev у Пети и у Маши — независимые истории.
A>Если Маша и Петя станут путаться, они могут начать использовать и локальные закладки, и синхронизируемые закладки, и именованные ветки. Например, в самом простом варианте, Маша может пометить локальной закладкой свою головную ревизию и легко отличать её от всех остальных головных ревизий, если таковые возникнут; а Петя может ничего не делать, если его всё устраивает.
Как локальная закладка будет отслеживать голову именованной ветки? Никак.
A>Или они могут каждый сделать себе по закладке и сказать синхронизировать их между репозиториями.
Не могут. Проблема ровно та же: "Be aware that there is only one namespace for bookmarks — it is advised to prefix your local-only bookmarks to avoid conflicts with other users. "
A>Могут под свои задачи именованные ветки завести, если захотят или потребуется зачем-то.
Ветки же уже заведены — с именем "experiment". Надо будет кому-то из них ветку переименовывать, переписывая историю. А от этой истории уже могут другие зависимости существовать...
A>·> Почему их нужно насильно сталкивать лишь по тому, что у них случайно совпали имена — хз. A>Я думаю, слово "нужно" неверно. Устраивает базовый функционал анонимных веток? Пользуешься им. Испытываешь неудобства? Можешь использовать закладки и/или именованные ветки.
Как выяснилось выше — не могу, проблему они не решают.
A>>>5 — Петя увидел, что Маша внесла некоторые изменения в Петину фичу A>>>6 A>>>7 — Петя влил Машины изменения к себе, закоммитил, запушил и тоже пошёл домой. A>·>Кстати, интересно. Как Петя может посмотреть Машины изменения перед вливанием? Я правильно понимаю, что у него уже будет три безымянные головы? A>Я слово «влил» использовал не подумав, имея в виду merge Петей изменений, которые Маша сделала в Петину ветку. В результате не очень понимаю, о чём ты спрашиваешь. После того как Петя пришёл вечером, сделал коммит и выполнил pull, он действительно увидит три головные ревизии. Одна Машина, другая Петина, третья тоже Петина, но созданная Машей. Как он поймёт, что Маша что-то сделала в его ветке?
Вот. Уже внезапно стало три анонимные ветки, различать их стало ещё сложнее.
A>Если использовать только неименованные ветки, то просто увидит, что из одной из ревизий, над которыми он работал, выросла новая голова.
A>Если он знает, что ему так будет неудобно, он может озаботиться, например, использованием синхронизируемых закладок. Тогда он тоже увидит три головные ревизии, но они будут подписаны:
Та же проблема, имена закладок глобальны, да ещё и пушатся без спросу — думай тщательно каждый раз когда даёшь название.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Тогда остаётся понять, в чём же разница в условиях.
