Mercurial 1.3

отличная новость - спасибо

Новость радует. Ченджлог тоже.

Соболезную mpm.

И ещё этому говну нужон питон? Ещё один аргумент в пользу git.

а что есть дистрибутивы без питона?

> Экспериментальная поддержка вложенных репозиториев

Это хорошо, надеюсь теперь можно будет работать без посторонней сущности типа hg.forest

>И ещё этому говну нужон питон? Ещё один аргумент в пользу git.

alx_me * (*) (02.07.2009 11:29:16)

А что не так с питоном?

>А что не так с питоном?

Расовая ненависть некоторых членов социума :)

>И ещё этому говну нужон питон? Ещё один аргумент в пользу git.

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

> Ещё один аргумент в пользу git.

Этому говну нужен Перл. Еще один аргумент в пользу hg.

жаль не нашел в нем такой же штуки как git-svn.

git вообще то теряет базы. Так сказал Торвалдс и добавил что так как
система распределенная то можно всегда востановить от друга ;)

Плагиат! Я хотел это сказать.

Такая штука есть.

Я думаю так: если ты сидишь под линаксом, то надо юзать cvs от Создателя, то есть git, а не богомерзкую поделку на петоне.

>Расовая ненависть некоторых членов социума :)

http://www.youtube.com/watch?v=MQMQZ6n1NZg

ыгы

> Я думаю так: если ты сидишь под линаксом, то надо юзать cvs от Создателя, то есть git, а не богомерзкую поделку на пистоне.

Вот так, полный логопедец.

> Добавлена опция patch.eol для работы с кроссплатформенными патчами

Слава яйцам! Конец моим мучениям!

никто не знает: автоматического переноса текущих изменений на другой бранч, как в git-е, не планируется?

Такой вопрос к апологетам mercurial'а: как можно сконвертировать существующий git-репозиторий в репозиторий mercurial'а?

rebase что-ли? есть, уже полгода как.

http://mercurial.selenic.com/wiki/ConvertExtension

> жаль не нашел в нем такой же штуки как git-svn.

Они просто не доведены до ума... http://mercurial.selenic.com/wiki/WorkingWithSubversion

> rebase что-ли?

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

>> rebase что-ли?

> мой hg такой команды не знает.

Какой он версии?

> работал ты не в том бранче, то при git checkout <нужный бранч>, накоденные изменения будут аккуратно вырезаны из текущего бранча, и объединены с нужным.

По описанию таки похоже на rebase

В терминологии mercurial это называется transplant.

>> Walter Gordon Heffron, who ... passed away yesterday.

>отличная новость - спасибо >real_maverick * (*) (02.07.2009 10:42:00)

отличный комент - спасибо

> В терминологии mercurial это называется transplant.

Нет, transplant - это совершенно другая вещь.

git.

> Какой он версии?

1.2.1. в gentoo нет свежее, только 9999.

> 1.2.1

Должно быть.

Enable the extension in the configuration file (.hgrc):

[extensions] hgext.rebase =

> [extensions]

> hgext.rebase =

ага, вот оно как… спасибо большое. почему-то в gentoo вообще никакой глобальный hgrc не ставится.

> Я думаю так: если ты сидишь под линаксом, то надо юзать cvs от
> Создателя, то есть git, а не богомерзкую поделку на петоне.

Круто.

Те если создатель юзает у себя на столе Gnome под Fedora то и остальные
должны точно также ? ;)

Где в git perl?

> Где в git perl?

В зависимостях.

сконвертировать - да, convert

а можно работать с git-сервером прямо из hg: http://hg-git.github.com/

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

> В зависимостях.

Можно и без perl его собирать.

>Можно и без perl его собирать.

И как это повлияет на функционал? Чего не будет?

> Чего не будет?

В собственно git-core почти ничего не изменится (git олдскульно сделан - на Си и шелле), но вся обвязка типа git-web и git-{svn,cvs,...} - перловая.

Тогда пересоберу с USE="-perl", поскольку для репозитория конфигов мне эти свистоперделки не особо нужны.

> Тогда пересоберу с USE="-perl",

Вряд ли это поддерживается сейчас. Я говорил о том, что переписать git-core без Перла - нетрудно.

в ebuild-е прямо написано perl? (dev-lang/perl)

Ну что, кто-нибудь уже заценил? Интересует чем принципиально отличается subrepos от hgext.forest

> Интересует чем принципиально отличается subrepos от hgext.forest

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

а ведётся какая-то [активная] работа в этом направлении? И что насчёт итеративного перетаскивания из/в git'овый репозиторий (про tailor знаю, интересны "нативные" средства :) )

>И что насчёт итеративного перетаскивания из/в git'овый репозиторий (про tailor знаю, интересны "нативные" средства :) )

насчет git и итеративности, как уже было сказано: http://hg-git.github.com/

Исходный посыл:

>изменения будут аккуратно вырезаны из текущего бранча, и объединены с нужным

Трансплант:

>allows you to transplant patches from another branch or repository

Ребейз:

>"detach" the local changes, synchronize the repository with the mainstream and then append the private changes on top of the new remote changes

Ты что-то путаешь.

> # Экспериментальная поддержка вложенных репозиториев

O_O а это как и зачем??

а, вссе, нашел. клевая штука :)

Юникод так и не прикрутили.