Вышел Mercurial 1.4!

> хаскелисты переходят на нормальную систему контроля версий - git

отличнаяшутка.jpg

>> Для Mercurial есть очень приличный кросплатформенный GUI - TortoiseHG

А под Linux оно с наутилусом интегрится или как?

По слухам, да.

Про переименование — бред.

Где то что вы написали противоречит тому, что написал я?

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

> Что-то ты сочиняешь.

Отлично если так. Я на своем опыте с коллегой юзаем один репозиторий git. Делали такой тест - он делает модификации и я делаю в одм файле только я вначале он в конце файла. В зависимости от того что делает push первым - у того хорошо, у второго - конфликт естественно. Вопрос: что мы делаем не так? Может надо как-то по-другому - если есть решение проблемы - буду только рад.

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

Ага, всего лишь поискать в двух коммитах файл с изменившимся хэшем (там, где у hg есть явная запись о переименовании). Это не говоря о случае «переименование и изменение», когда git должен вычислить сходство файлов, чтобы определить факт переименования (и делать это каждый раз при просмотре истории). Очень эффективно, да :D

> В зависимости от того что делает push первым - у того хорошо, у второго - конфликт естественно.

Конфликт на push? O_O

> В зависимости от того что делает push первым - у того хорошо, у второго - конфликт естественно.

push просто дописывает все changeset-ы в другой репозиторий. Если у двух коммитов был один и тот-же parent, то просто появятся дополнительные head-ы, которые дальше нужно мержить.

Mercurial по умолчанию на эти самые дополнительные head-ы проверят и отказывается push-ить если они есть. Но это обходится ключем -f (либо в hgrc)

Вопрос: что мы делаем не так? Может надо как-то по-другому - если есть решение проблемы - буду только рад.

У вас нехватает шага merge либо rebase.

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

> Есть ли хоть одна система которая умеет такие вещи разруливать сама? А может быть git такое уже умеет?..

ололо, толстячек ;)

меркуриал не нужен, есть же кошерный http://www.fossil-scm.org .

> ололо, толстячек ;)

Молчать, школота =) Ни разу не было намерения троллить или чего-то подобного.

http://bitbucket.org/tortoisehg/stable/wiki/Home

Supported Platforms

* Microsoft Windows XP, Vista, Windows 7
* Command line support via hgtk
* Gnome/Nautilus integration
* Mac OS X port is in progress

> * Gnome/Nautilus integration

Ну я и говорю - «по слухам» :) Сам не пробовал.

>> * Gnome/Nautilus integration

>Ну я и говорю - "по слухам" :) Сам не пробовал.

:) Ясно. Тогда могу сказать что работает не только по слухам.
Статусы файлов отображает, все действия доступны из контекстного меню, UI в новой версии (0.9) очень радует.

> В git-е например при попытке редактировать файл одновременно - возникает конфликт

8-0 _разные_ части? Что-то в консерватории не так. Если коллизия может быть разрешена соотнесением с двумя разными неизменяющимися контекстами (обычно, +/-3 строчки вокруг изменяемого фрагмента) - она будет разрешена без конфликта.

> Ага, всего лишь поискать в двух коммитах файл с изменившимся хэшем (там, где у hg есть явная запись о переименовании). Это не говоря о случае «переименование и изменение», когда git должен вычислить сходство файлов, чтобы определить факт переименования (и делать это каждый раз при просмотре истории). Очень эффективно, да :D

На практике - отлично работает. Даже в проектах с сотнями тысяч ревизий и тысячами, если не десятками тысяч файлов. Имею практический опыт.

> но не ожидал что для простейших операций типа редактирования одного файла придется это использовать, а стало быть надо хранить две ветки...

:) Вас спасёт rebase. Я серьёзно, для случая, когда команда работает в пределах одной ветки лучше использовать merge/pull --rebase (или явный rebase после fetch). В принципе, это настраивается для каждой конкретной ветки в конфигах.

Кстати говоря, наши hg'кнутые друзья в этом месте, кажется, имеют более автоматизированную процедуру. Но по сути, всё это - с точностью до набора командочек в крохотном батничке, реализующем логику update.

> На практике - отлично работает.

А кто-то говорил, что не работает? Речь шла об «эффективно».

Эффективно - это значит «без раздражающих задержек» ? Именно так, good enough.

> А кто-то говорил, что не работает? Речь шла об «эффективно».

Лучше за hg'шный syntax sugar для svn'щиков расскажите, право слово. И мне, и большинству аудитории будет интереснее.

Практика показала, что люди, «прибитые к CVS/SVN workflow» и не очень желающие вникать в новые парадигмы, предоставляемые git, трудновато привыкают к git'овым реалиям. При этом, я не могу обвинить людей в технической некомпетентности или там, скажем, саботаже. Хотя, опять же, из практики, через некоторое время git настолько въедается в пальцы, что всё остальное кажется неудобным.

> Эффективно - это значит «без раздражающих задержек» ?

Нет. Это значит, «с наименьшими затратами ресурсов».

Лучше за hg'шный syntax sugar для svn'щиков расскажите, право слово.

За набор команд hg? Так он для всех, а не только для svn'щиков.

Практика показала, что люди, «прибитые к CVS/SVN workflow» и не очень желающие вникать в новые парадигмы, предоставляемые git, трудновато привыкают к git'овым реалиям.

Практика показывает, что Git мешает им привыкать к новому workflow своим странным набором команд и высосанной^Wпричудливой терминологией.

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

Я таким всегда советую прочитать рассказ Габышева «Люсик» ;)

Что-то Вы какой-то неконструктивно настроенный. Не хотите рассказывать - ну, в общем, Ваше право. Замечу только, что «набор команд» не решает, решает «разбор полётов» для юзкейсов, типичных для среднестатистического пользователя, пришедшего с CVS, SVN и далее по списку.

«С наименьшими затратами ресурсов» - Чьих? Машинных? Тогда, увы, это сразу не про питон. Заметьте, я не имею ничего против языка, и не имею ничего против того, что hg на нём написан, но моё определение эффективности и не включает такой довольно жёсткой (по крайней мере, с точки зрения математики) и не слишком полезной сущности, как «наименьшие затраты машинных ресурсов».