Вышел Mercurial 1.9

Как-то это не сочетается с изначальной философией hg: неизменяемостью истории.

> Как-то это не сочетается с изначальной философией hg: неизменяемостью истории.

Думаю, именно поэтому и mq, и rebase до сих пор в hgext. Но, ИМХО, серьезное использование Mercurial без них не обходится.

Я тоже ими пользуюсь, но не ради сферического коня, сиречь, выпрямления истории. Иногда задалбывает мержить в 3-4 ветки, но в основном без проблем.
Надо признаться, однако, что я использую hg как backend к VSS/TFS :)

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

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

> использую hg как backend к VSS/TFS :)

Бэкенд или фронтенд?

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

Достаточное количество обезьян таки напечатают «Войну и мир» :)

Как я понимаю, это предполагает заводить ветви в репозитории, ветвить граф ревизий и плодить прочие сложности. Ветвь == директория, остальное все от лукавого, плодит сложности и превращает репозиторий в помойку.

Как я понимаю, это предполагает заводить ветви в репозитории

превращает репозиторий в помойку.

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

Эээ, фронтенд, конечно. Остальные коллеги жрут кактус.

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

Так же и в меркуриале.

Так же и в меркуриале.

AFAIK, их только недавно (год/полтора?) включили.

>> Я даже не знаю такой vcs, которая бы затирала историю.

Я знаю две - Mercurial и Git :)

В git есть локальный reflog, так что даже rebase не уничтожает историю полностью. В hg история, по-идее, вообще неизменяема. Или это уже поменялось?

С появлением mq.

>> В hg история, по-идее, вообще неизменяема. Или это уже поменялось?

С появлением mq.

...в далеком 2005 году :)

Ну, значит должен быть и эквивалент reflog'a. :)

> Ну, значит должен быть и эквивалент reflog'a. :)

mq не нужны эти костыли. rebase... может быть, но у него есть опция keep и, ИМХО, он используется редко.

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

> Почему костыли? Reflog даёт уверенность, что никакие данные не будут потеряны, даже если пользователь облажается и введёт не ту команду.

Reflog, ЕМНИП, был создан потому, что редактирование истории - это нормальная и поощряемая практика в Git, и поэтому ошибки, связанные с уничтожением истории, относительно часты.

Так почему костыли? И что плохого в редактировании истории?

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

Разработка в git выглядит таким образом: я эксперементирую, вариант, которым доволен, приглаживаю, после чего соединяю (rebase) commitы с добавляющие/исправляющие функционал и косметику и делаю push. В основном потоке всё должно выглядеть красиво - там не зачем видеть творческие мучения автора и весь мыслительный процесс до конечного результата. Поэтому таки, редактирование истории мне кажется нормальной и поощраемой практикой. Как выглядит процесс разработки с использованием hg?

> что мешало Mercurial поступать также? %) %) %)

Этот срач про имена файлов в mailing list-е mercurial-а поднимается наверное раз в пол года-год.

По сути проблема изначально в формате стореджа mercurial. Он, как и unix, воспринимает имя файла как тупой набор байт. Т.е. игнорируя понятие кодировки, как таковое.

Из-за этого и все баги. Венда тут совсем не причем. Проверяется элементарно: создается репозиторий с русскоязычными именами файлов на любом современном дистре с UTF-8 локалью. Дальше pull-им этот репозиторий на другую систему/другому юзеру с KOI8/еще чем. Естественно, что получим облом.

Аналогично и венда. Mercurial пользуется неюникодным API и сует туда тот же набор байт вместо имени файла (если репозиторий из современного linux, то UTF-8).

Т.е. тут банальный пофигизм. И нет никакой «проблемы» вендовой консоли/еще чего. К сожалению авторы тупо игнорируют проблему и тупо сьезжают на то что Make тоже понимает файлы как набор байт. Естественно, умалчивая, что кроме make бывают еще XML, HTML и куча других вещей, где можно явно указать кодировку.

Рабочий пример — SVN. Внутри он хранит имена файлов всегда в юникоде. И можно коммитить русскоязычные имена файлы пользователем разных локалей (главное чтоб в ней были все необходимые символы). И на венде это тоже прекрасно работает.

Пруфы:

http://www.selenic.com/pipermail/mercurial/2008-August/020670.html

http://www.selenic.com/pipermail/mercurial/2008-June/019731.html

Точно такой же срач работает и в git:

http://kerneltrap.org/?q=mailarchive/git/2008/1/20/584912