Python переходит на Mercurial

> Как будто этот алгоритм будет отличаться от того, что использует git status. Разработчики, видимо, мазохисты и написали два различных алгоритма, ага.

Факт в том, что Git не хранит данных о переименовании, а вычиляет их каждый раз.

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

Осиль разницу между языком и его интерпретатором.

>Нет, ты. Сказал, что у Питона используется "мультипроджект" - выложи нам репозиторий Питона.

Это от кактуса меркуриала так торкает? Хм видимо я рано с него свалил.

>Белки приучены грызть грабли :D

Они их подкладывают.

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

> Это от кактуса меркуриала так торкает

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

>> Белки приучены грызть грабли :D

> Они их подкладывают.

Одно другому не мешает %)

> Типа OpenSolaris, JDK, Mozilla и Python? Ну не всем же быть столь крутыми, как лоровские белки :)

А теперь прикинь, появляется новость, что OpenSolaris перешел на git. Куда пойдут его пользователи? :-)

Идеология, однако.

> А теперь прикинь, появляется новость, что OpenSolaris перешел на git. Куда пойдут его пользователи? :-)

А прикинь, такой новости не появится. Куда ты пойдешь?

> Идеология, однако.

Ты смешон, правда. Иди почитай о процедуре выбора DVCS для OpenSolaris.

> Осиль разницу между языком и его интерпретатором.

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

>за спиной каждого коммиттера сидят пара-тройка девелоперов, которе не имеют никакого правa комиттить в SVN

Пусть кинет в меня камень тот, кто аргументированно заявит, что под такую модель DVCS подходят хуже!

>> А теперь прикинь, появляется новость, что OpenSolaris перешел на git. Куда пойдут его пользователи? :-)

>А прикинь, такой новости не появится. Куда ты пойдешь?

Про то и писал, что ее не появится.

>> Идеология, однако.

> Ты смешон, правда. Иди почитай о процедуре выбора DVCS для OpenSolaris.

На заборе тоже написано. Почитай про заботу о пользователях в рекламе от MS.

Хочешь посмеяться - смейся.

>> Ты смешон, правда. Иди почитай о процедуре выбора DVCS для OpenSolaris.

> На заборе тоже написано.

То есть не читал и не будешь. Дело твое.

> Хочешь посмеяться - смейся.

Уже.

> Для питона ее нет.

Да ну? ironpython, pypy, jython, etc(лень гуглить что ещё изобрели)...

Гвидо, по его словам, кодом cpython не занимается, он занимается развитием самого языка а не конкретной реализации.

2Valeriy_Onuchin

>моё мнение: >1. Mercurial - не нужен >2. всё это "корпоративщина", PR от Гвидо ван Россумa

А может всетаки прежде чем высказывать мнение разобраться надо? Да и вообще если устриц не пробовал....

У меня например 3 репозитория. 1 Дома 1 На работе 1 на Флешке. Если надо делаю хоть 100 репов. Ваша иерархия с СВН это от бессилия

CVS служил верой и правдой многие годы и его функций хватало всем , а то что явились новые vcs так это эволюция . Все vcs нужны.

> Как только git научится работать с удалёнными FS

Кстати, да.

git не работает в каталоге, подключённом с sshfs

В чём дело?

> CVS служил верой и правдой многие годы и его функций хватало всем

Не всем :) Мне на хватало - я начал пользоваться VCS только с выходом SVN. А Линус был настолько суров, что и SVN не стал пользоваться.

>Кстати, да.

>git не работает в каталоге, подключённом с sshfs

>В чём дело?

А вы тему-то прочтите внимательно.

Не всем :) Мне на хватало - я начал пользоваться VCS только с выходом SVN

Тоесть до выхода SVN вы работали без системы учета версий ? Ну что ж коллега поздравляю вы выстояли это время героически ;)

>CVS служил верой и правдой многие годы и его функций хватало всем

Неправда ваша. Мне не хватало в своё время прежде всего атомарных коммитов (коммит не разбивается на файлы) и раздражало непонятно чем продиктованное версионирование.

>> Не всем :) Мне на хватало - я начал пользоваться VCS только с выходом SVN

> Тоесть до выхода SVN вы работали без системы учета версий ?

Ну не совсем. Мы делали снэпшоты в arj, zip или tar.gz.

> Ну что ж коллега поздравляю вы выстояли это время героически ;)

Я даже больше скажу - я лично пытался асилить CVS, и каждый раз отступал в недоумении :)

По моему в этом и есть кайф что бы не заморачиваться на циферках.

Ну не совсем. Мы делали снэпшоты в arj, zip или tar.gz.

Вы знаете помоему проще все таки осилить cvs чем столь извращаться не так ли? Позвольте узнать какой же дополнительный фунционал несет сей извращеный способ ?

>> Ну не совсем. Мы делали снэпшоты в arj, zip или tar.gz.

> Вы знаете помоему проще все таки осилить cvs чем столь извращаться не так ли?

Я посчитал, что не так.

> Позвольте узнать какой же дополнительный фунционал несет сей извращеный способ ?

Дополнительного - никакого не нес.

Давно пора. Молодцы, правильный выбор.

> SVN по сравнению с Mercurial - прошлый век (я пользователь SVN с версии 0.14).

он может 10 раз прошлый быть, но для проекта, который пишет один человек (а также 2, 3 или 4), необходимость DVCS малопонятна...

>он может 10 раз прошлый быть, но для проекта, который пишет один человек (а также 2, 3 или 4), необходимость DVCS малопонятна...

Юзаю DVCS для личных проектов, ибо:
1. привычка к одному DVCS
2. кто-угодно из DVCS быстрее SVN
3. распределенность это фича - не хочешь, не юзаешь
4. Иногда надо переходить с компа на ноут и назад

> для проекта, который пишет один человек (а также 2, 3 или 4), необходимость DVCS малопонятна...

Mercurial просто лучше. Если добавить к нему mq, он намного лучше, и распределенность здесь не причем,

>но для проекта, который пишет один человек (а также 2, 3 или 4), необходимость DVCS малопонятна...

Как раз, когда работаешь в одиночку, DVCS - это верх удобства. Говорю по своей практике. А вот в DVCS в большой команде раздолбаев - это, до сих пор считаю, вред делу. Половину всей работы будешь тратить на слияние бранчей и тестирование вылезающих из-за этого багов :)

А вот в одиночку - милое дело. Репа дома, репа на боевом сервере, пару реп на работе - и всё это сводится только так, как тебе нужно.

> Как раз, когда работаешь в одиночку, DVCS - это верх удобства.

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

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

Категорически не согласен. Поднимается центральный сервер, на котором запрещены несколько head-ов в основном бранче. В результате тот, кто хочет отдать свои изменения на сервер, должен подтянуть изменения с сервера и сам всё смержить перед отдачей. Т.е. здесь отличия от svn нет. А вот дополнительные удобства есть: коммитишь себе локально и не паришься. Потом мержишь head-ы отдельным коммитом. Т.е. мухи - отдельно, котлеты - отдельно.

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

> http://www.whygitisbetterthanx.com/#git-is-fast

Интересный обзор - прочитав его понял следующие два факта:

1. Команда add у git самая медленная.

2. svn checkout самый быстрый среди всех рассмотренных систем.

иными словами git-is-fast-in-all-operations-except-add-and-it-is-slower-than-svn-checkout

>Поднимается центральный сервер, на котором запрещены несколько head-ов в основном бранче.

А, ну, если так. Просто не попадалась на глаза такая возможность. Надо будет попробовать.

>Просто не попадалась на глаза такая возможность. Надо будет попробовать.

Ну меркуриал визжит диким голосом, если push добавляет голову. Этого недостаточно?

> он может 10 раз прошлый быть, но для проекта, который пишет один человек

у меня не всегда есть инет, а без доступа к центральному репозиторию(история проекта итп) svn бесполезен. А вот с git я могу работать и без доступа в инет, главное конфликтов не насажать. И копия репозитория у меня на ноуте и домашней тачке, тут уже распределённые системы лучше подходят.

> Ну меркуриал визжит диким голосом, если push добавляет голову.

Ага, я это и имел ввиду - при попытке сделать push, который создаёт head, сервер давал отлуп. Возможно там специально и конфигурить ничего не надо (сервер поднимал не я, поэтому точно не знаю).

>конфигурить ничего не надо

Именно так, он по умолчанию настроен на сопротивление такому всеми силами.

> при попытке сделать push, который создаёт head, сервер давал отлуп. Возможно там специально и конфигурить ничего не надо

Надо. По умолчанию сервер не возражает против нескольких голов. Чтобы возражал, надо писАть хук.

Ась?

$ hg init test
$ cd test/
$ vi README
$ hg add
adding README
$ hg ci
$ cd ..
$ hg clone test/ test2
updating working directory
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ cd test
$ vi README 
$ hg ci
$ cd ../test2/
$ vi README 
$ hg ci 
$ cd ../test
$ hg serve &
$ cd ../test2/
$ hg push http://localhost:8000
abort: push creates new remote heads!
(did you forget to merge? use push -f to force)

> Ась?

Штоа?

> (did you forget to merge? use push -f to force)

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

P.S. vi сосет :D

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

Разумеется. Но от невнимательности дефолтное поведение спасает и без хука.

>P.S. vi сосет :D

А вот сейчас как расскажу всем, что ты mcedit юзаешь!

> от невнимательности дефолтное поведение спасает и без хука.

"Добпым словом и пистолетом^Wхуком на сервере можно сделать гораздо больше, чем просто добрым словом" (c)

>> P.S. vi сосет :D

> А вот сейчас как расскажу всем, что ты mcedit юзаешь!

Ибо он рулит безжалостно.

>"Добпым словом и пистолетом^Wхуком на сервере можно сделать гораздо больше, чем просто добрым словом" (c)

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

>Ибо он рулит безжалостно.

Взрослый дядько, а поделием для виндузятников пользуется. Тьфу!

>Ну меркуриал визжит диким голосом, если push добавляет голову. Этого недостаточно?

Не-а. Я же писал про раздолбаев-разработчиков.

>>Ну меркуриал визжит диким голосом, если push добавляет голову. Этого недостаточно?

>Не-а. Я же писал про раздолбаев-разработчиков.

Это уже вредители какие-то. Тех, кто делает push -f, надо увольнять после первого предупреждения, потому что такие действия говорят о полном непонимании процесса коллективной разработки.

> Тех, кто делает push -f, надо увольнять после первого предупреждения

Слова Крона о коллективе раздолбаев относились к коллективу вольных прогеров, которых хрен уволишь :)

>относились к коллективу вольных прогеров, которых хрен уволишь

Угу, именно. И если таких «увольнять» проект просто накрывается :)

Угу, сталкивался с такой особенностью опенсорса. :) Как говорят на Украине, маемо, що маемо.

Ну так они и в svn накоммитят такого, что сутками потом разгребать надо. Лучше таким прав на запись в trunk не давать, а просить присылать патчи. MQ, опять же, тут хорошо поможет - ты работаешь с патчами как с обычными ченджсетами. Чтоб никого не обижать, завести такую процедуру для всех: новый код попадает в центральный репозитарий только после ревью одним из мэнтейнеров.

>Бгг. Таких базовых вещей не знать %)

"Базовые вещи" - это то, что git работает не с файлами, а контентом. Поэтому именно ПЕРЕМЕЩЕНИЕ файлов он, действительно, не отслеживает. Он отслеживает перемещение контента.

Кстати, как раз поэтому операция "add" у него и медленная.

> Он отслеживает перемещение контента.

Он его не отслеживает, он его вычисляет.

> Кстати, как раз поэтому операция "add" у него и медленная.

И вовсе не поэтому. add добавляет объект в базу, что в других vcs обычно является частью операции commit. Что же вы гитстеры такие безграмонтные.

> Python переходит на Mercurial

А Java-разработчики, кто успел прочухать, уже на Maven — уж он-то посильнее традиционных DVCS:
http://www.ibm.com/developerworks/ru/edu/j-mavenv2/section2.html