Завершен переход Perl на Git

>Ранее, с 1997 года, в проекте использовалась коммерческая система управления версиями Perforce

ад какой. я понимаю, почему они отказались от Perforce,- но зачем они эту дрянь вообще использовали?..

Вероятно, затем же, зачем и Trolltech: энтерпрайзно, глобально и надежно.

>Вероятно, затем же, зачем и Trolltech: энтерпрайзно, глобально и надежно.

и адски неудобно вдобавок. хорошо что ушли от этого монстра, поддерживаю :)

А какие недостатки у SVN?

Честно говоря ничего не коммитил никогда, но субьективно, с гит репозитория шустрее код сливается

вот: www.youtube.com/watch?v=4XpnKHJAok8

Торвальдс подробно рассказывает какие недостатки у cvs и svn
и все кто ими пользуется тупые уроды

> Торвальдс подробно рассказывает какие недостатки у cvs и svn
> и все кто ими пользуется тупые уроды

А bazaar?

"A little exploration turned up that Linus' git stuff is a bit wonky in a lot of ways. It's a few c programs surrounded by a slew of scripts of varying quality, and not many tools for. Mercurial, on the other hand, tackles the same problems, but is written in Python, well supported, well documented and seems to have a lot of momentum in the OSS community."

На старой работе был сначала cvs, потом мы пробили переход на svn.

На новой работе стоит перфорс - глюкавое пропиетарное поделие. После svn-а меня от него тошнит. В топку.

сам несколько лет использовал svn (до этого cvs), но после перехода на Mercurial(hg) получил удовольствие и ни за что не вернусь к устаревшим централизованным VCS для своих проектов.

Переход на git или (hg) - верное решение!

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

>ад какой. я понимаю, почему они отказались от Perforce,- но зачем они эту дрянь вообще использовали?..

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

Т.е. уже можно официально заявлять: "Гит на два порядка превосходит по всем параметрам глюкавое говно под названием `перфорс`"?

а чем собственно так плох перфорс?
кроме того что не распределенный

>и все кто ими пользуется тупые уроды

Всего лишь мазохисты.

>вот: www.youtube.com/watch?v=4XpnKHJAok8
Торвальдс подробно рассказывает какие недостатки у cvs и svn
и все кто ими пользуется тупые уроды

Люди, а есть перевод или хоть субтитры к этому. а то английский на слух не воспринимаю. Только письменно.

Подробно говоришь? На какой минуте?

>и все кто ими пользуется тупые уроды

ну да, а анонимус который ничего не делает всех умнее дада.

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

Предупреждая - первый недостаток git - к примеру я случаем удалил файл - cvs update мне его скатает - git будет ругатся, часто возникает потребность вообще сменить его, так что тут не слишком удобственно, но в cvs чтобы сделать отдельный бранч, потом все это смержить, и плюс ко всему всегда иметь доступ к cvs серверу - это конечно тоже сильно не удобно.

В любом случае - если проект мелкий и работает до 3-4 человек - то cvs самое оно, если проект крупный и работает над ним более 3 человек - то без git никуда если хочется поэкономить время.

попробуй mercurial. по сравнению с git - просто праздник.

Я раньше отчего злой был? Потому что у меня велосипеда не было

git reset --hard HEAD не поможет вам? и ключик -f у checkout?

былобы забавно еслиб они на меркуриал перешли

>Люди, а есть перевод или хоть субтитры к этому. а то английский на слух не воспринимаю. Только письменно.

Я потихоньку субтитры ваяю, где-то после нового года будут

> Торвальдс подробно рассказывает какие недостатки у cvs и svn
и все кто ими пользуется тупые уроды

прикольно

> Люди, а есть перевод или хоть субтитры к этому. а то английский на слух не воспринимаю. Только письменно.

Это решается. Надо чтобы мозг научился различать язык. Учится тупым прослушиванием диалогов. Берешь диалог на 30 сек, без посторонних звуков и пауз. Ставишь этот диалог на воспроизведение по кругу и слушаешь до тех пор, пока не различишь каждую фонему. Без сопроводительного текста! Только на слух!

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

Git FTW!

Тут товарищи на перфорс наезжают. А почему, собсно? Интересно бы конкретики. Я вот долго работаю с нею. Инструмент своебразный, заточенный под конкретную модель работы - т.н. кафедральную. Например, ВСЕ метаданные на сервере. Со всеми отсюда вытекающими геморроями, если не дай бог вы захотите чего сделать будучи от сервера отключённым. Поэтому я вообще в шоке что пёрл на нём держали. По сути. Если вы под перфорс подстроились, там много прелестей. Например, очень мощный обобщённый инструмент продвижения ревизий по веткам -- integrate (а ветки - суть директории, никакого лишнего оверхэда). Концепция views -- прелесть. Вас неустраивает как организован код в репозитории? Вы работаете с (возможно, вашей частной) веткой запрятанной где-то в недрах древа? Пожалуйста, разрулите всё это в вашем клиенте как вам угодно. В совокупности integrate и views по моему в полне позволяют работать в стиле распределённых вещиц типа git, на сколько я его понимаю (самому ёще не приходилось трогать) -- в пределах "собора". Ещё радует тем что есть отличный GUI (p4v) с красивым графом ревизий и встроенным удобным инструментом 3-way merge. Кстати сказать, GUI работает абсолютно одинаково (безупречно) что под виндой, что на линукхе, что на самом деле не так уж часто встречаешь. Да, старый клиент P4Win действительно был дерьмом -- зато CLI клиент полноценный всегда выручает -- закачивайте его в find с xargs по полной фене. Короче, ИМХО для серьёзных проектов в закрытой, корпоративной парадигме, и для людей которые способны проникнутся ейным стилем -- perforce вещь довольно мощная, и в то же время лёгкая и шустрая (линуксовая х86_64 p4 весит 584К и зависит тока от libc).

Да? А я например итальянский без проблем на фонемы разделяю. А понимать почему-то непонимаю. Что же мне делать?

>былобы забавно еслиб они на меркуриал перешли

+1

perl на проекте, сделанном на python :)

>perl на проекте^Wподелке, сделанном^Wсляпаном на python :)

fixed

> fixed

А торвальдс сказал что меркуриал хороший проект! Кому мне теперь верить, ТЕБЕ или Торвальдсу?

>А торвальдс сказал что меркуриал хороший проект! Кому мне теперь верить, ТЕБЕ или Торвальдсу?

Ты главное - верь!:)

> Кому мне теперь верить, ТЕБЕ или Торвальдсу?

Анонимный брат, ты что? Это же Led - если ты его еще хоть немного покормишь, он лопнет нафиг, сколько грязи будет.

http://git.or.cz/gitwiki/LinusTalk200705Transcript

Why not svn or cvs ?

> http://git.or.cz/gitwiki/LinusTalk200705Transcript

Интересная лекция. Правда, местами неубедительно, ИМХО.

Уже ж объяснили - что пользователи cvs/svn - тупое бездарное быдло с мазохистическими наклонностями :)))

>> Подробно говоришь? На какой минуте?

> You can disagree with me as much as you want, but during this talk, by definition, anybody who disagrees is stupid and ugly, so keep that in mind. When I am done speaking, you can go on with your lives. Right now, yes, I have strong opinions, and CVS users, if you actually like using CVS, you shouldn't be here. You should be in some mental institution, somewhere else.

Цитата из лекции: "if you moved a function from one file to another, git will literally tell you the history of that function even across that move. Not a file move. A function within a file"

Git в самом деле такое умеет?

>А какие недостатки у SVN?

Им нужно было распределенная система, а SVN - централизованная.

Хотя читал маны по git / bzr - нужно больше знать о система чтобы корректно использовать. ИМО если не требуется распределенность, то SVN лучше.

Опять же что git что bzr не умеют держать один репозиторий на много проектов и checkout + commit поддиректории.

> ИМО если не требуется распределенность, то SVN лучше.

Это не так. Просто используй Mercurial+MQ, а не git.

>> ИМО если не требуется распределенность, то SVN лучше.

> Это не так. Просто используй Mercurial+MQ, а не git.

есть тынц как поставить Mercurial и какие инструменты типа TortoiseSVN для него есть?

Главное что пока я не понимаю как объединяются ветки. В SVN ветки создаются СПЕЦИАЛЬНО, потому обычно разработка идет в trunk и каждый при комитте делает update после чего код вливается в trunk.

Как я понял, mercurial создаст бранч автоматом на 2-коммита к одной ревизии и затем ПРИДЕТСЯ дополнительно мержиться???

> Это не так. Просто используй Mercurial

Насколько сложно реализовать работу типа как с SVN при использовании Mercurial?

workflow:
svn checkout
%LOOP% <coding> svn update svn commit

>> ИМО если не требуется распределенность, то SVN лучше.

>Это не так. Просто используй Mercurial+MQ, а не git.

Цитата с сайта hg:
Many SVN/CVS users expect to host related projects together in one repository. This is really not what hg was made for, so you should try a different way of working.

для нашей системы работы - огромный минус. скорее всего перекрывающий плюсы децентрализованности.

>Люди, а есть перевод или хоть субтитры к этому. а то английский на слух не воспринимаю. Только письменно.

Перевод кого, Линуса? Ну он там всех обзывает мастурбирующими обезьянами и говорит о веществах и еще советует всем обратиться к психиатру =)

> как поставить Mercurial и какие инструменты типа TortoiseSVN для него есть?

apt-get install mercurial :)

Для Венды есть бинарная сборка. AFAIK, есть и TortoiseHg. http://www.selenic.com/mercurial/wiki/index.cgi/BinaryPackages

> В SVN ветки создаются СПЕЦИАЛЬНО, потому обычно разработка идет в trunk и каждый при комитте делает update после чего код вливается в trunk.

Это не совсем так - если ты изменил файлы, которые кто-то другой изменил до тебя, ты должен сделать svn up в рабочей копии, и только потом сервер разрешит тебе svn ci.

> Как я понял, mercurial создаст бранч автоматом на 2-коммита к одной ревизии и затем ПРИДЕТСЯ дополнительно мержиться???

[Вообще-то бранч создается и одним коммитом]

Если есть что мержить, то мержить нужно (ну то есть это не требуется жестко, но рано или поздно придется). Но в 90% случаев это 2 команды - "hg pull; hg merge", потому что параллельные изменения обычно не конфликтуют; эти 2 команды - аналог приведенных выше "svn up; svn ci".

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

> . А понимать почему-то непонимаю. Что же мне делать?

Не знаешь письменный?

Между тем, большие проекты переходят на Subversion или GIT, но почему-то не Mercurial :)

ps
Да, и традиционно - Распределённые VCM нужны в редких, сугубоспецифичных ситуациях многоуровнового комита. К примеру в разработке ядра.

>Да, и традиционно - Распределённые VCM нужны в редких, сугубоспецифичных ситуациях многоуровнового комита. К примеру в разработке ядра.

Периодическая недоступность инета рассматривается как редкая и сугубо специфическая ситуация?

> cvs update мне его скатает - git будет ругатся, часто возникает потребность вообще сменить его

Для этого проще использовать git checkout -f

> Между тем, большие проекты переходят на Subversion или GIT, но почему-то не Mercurial :)

Да как раз понятно всё: SVN - это знакомая всем с тяжелого деццтва "CVS done right", у Git крутой пиар (и резкие как понос парни тип Кита Пакарда).

> Да, и традиционно

"Я знал, что ты это скажешь!" (c)

> Распределённые VCM нужны в редких, сугубоспецифичных ситуациях многоуровнового комита. К примеру в разработке ядра.

Но большие проекты переходят почему-то на Git :-P

Кстати, ты сам-то работал с BK, Mercurial, Git?