Цитата(bilbobagginz @ 25.11.2007, 03:36  ) |
| a SVN, это такое же Г**но, как CVS, только немного постабильнее. |
"а мужики-то не знают"...
чем svn г**но? и чем так заруливает git?
| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > Клуб юнуксоидов > Чем git лучше svn? |
| Автор: JackYF 25.11.2007, 12:50 | ||
"а мужики-то не знают"... чем svn г**но? и чем так заруливает git? |
| Автор: bilbobagginz 26.11.2007, 00:42 |
| тем, что, вот сидишь ты в поезде/самолете/автобусе, едешь домой, с ноутом, и можешь себе представить вот у тебя гениальная наработка в голове появилась. ну ты ее начал реализовывать, запудрился, и приехав домой, решил делать по-другому, потому как оригинальный код ты уже изменил до неузнаваемости. а как было бы хорошо закоммитить несколько раз в пути. правда ?мог бы сделать несколько коммитов в пути, и к ним вернуться ... но сделать этого с svn - нельзя без заморочек: сервер то не доступен, а рабочая копия не коммитится... вот и облом: нужно создавать свой репозиторий, в него импортировать твой код, а потом корячиться всю ветку вставлять в основной репозитарий. довольно неудобно. svn - и в концепции и в реализации основан на централизованном сервере, будь то apache или svnserve. есть куча - репозитарий, и все в нее кидают лопатой, когда можно. почему так ? потому что слияние веток настолько неудобно, что никто не хочет много раз его делать. git - распределен по определению. могет толкать ветку в чужой репозитарий, вкл, всю историю. а могет не толкать. по определению "центрального сервера" как такового - нет. каждый что-то пишет и делает. в какой-то момент, он решает, что какую-то ветку он готов "разрешить другим посмотреть". и дает он свой код менеджеру. менеджер - посмотрел код, и слил всё в одну ветку. менеджер - бекапится. девелопер бекапится. вот и создается распределенная сеть веток  он еще чуточку сыроват для компаний с большим кол-вом кодеров под виндой: нет гуя для винды, нет всяких рюшек и т.д. но функционал отличный. кроме того, особое внимание там уделили легкости слияния веток и разделения на них, т.е. merge/branch. и всё работает побыстрее svn. ессно kernel.org уже переходит постепенно на git. всем удачи. |
| Автор: JackYF 26.11.2007, 01:07 | ||||
жёсткие аргументы... меня вот только одно интересует: х знает когда появилась cvs, потом не так давно появилась svn, в которой явно постарались убрать недостатки cvs'a... и что, никто не догадался сделать "нормальный" merge/branch? странно это всё. Жалко, я не пробовал, у меня таких задач не стояло. Но как-нибудь на git надо посмотреть. P.S. так чего же многие крупные проекты до сих пор используют "неудобные" cvs/svn, неужели они про git не знают? Или, всё-таки, не так уж коряво сделан merge/branch в том же svn?
Можешь объяснить, в чём неудобность? и удобство git'a? |
| Автор: bilbobagginz 26.11.2007, 06:31 | ||||
потому что тулзу придумал линус торвалдс совсем недавно - 2 года назад http://ru.wikipedia.org/wiki/Git и нет еще родных клиентов по винду (только через cygwin или mingw ),
в стандартных системах визуализация истории сделана по-другому, и инструменты работают криво. напр. cvs - у каждого файла свой номер версии. черт голову сломит. смотришь на всё это и офигеваешь. читай англ. статью: http://en.wikipedia.org/wiki/Git_(software) в принципе уже сейчас можно ее внедрять, если не против пока на конечных клиентах винды работать из опд cvs/svn клиентов ( гит поддерживает такой расклад ) короче, читайте читайте... |
| Автор: JackYF 26.11.2007, 15:11 | ||
вот я юзаю svn. Что у меня криво работает-то? Номер версии у всех файлов один и тот же. Wtf "визуализация истории"? Всё равно я одними консольными клиентами пользуюсь... |
| Автор: nickless 26.11.2007, 23:57 | ||
git распределённый, svn нет, у каждого свои достоинства и недостатки, чего спорить то
И каждый должен не забывать бэкапится, а если есть сервер - бэкапится только центральный репозиторий и гемора девелоперам получается меньше  Так что в болъших фирмах это не такое уж и преймущество, а вот в опенсурсных проектах вроде ядра - наоборот. |
| Автор: JackYF 27.11.2007, 00:07 |
| Создал тему в религиозных войнах, чтобы здесь не оффтопить |
| Автор: bilbobagginz 28.11.2007, 01:47 | ||
| в клубе по внутренним правилам можно немного культурно пофлеймить. nickless, с т.з. фирмы -
да это так, если в большой фирме запретить поднимать пару сильных и хорошо забекапленных серверов но ведь это не запрещено законом. следовательно git приносит новую концепцию, не теряя старого функционала. не правда ли ? и вообще с т.з. клиента git может изображать из себя и cvs сервер... так, для отвода глаз : ) |
| Автор: nickless 28.11.2007, 21:56 | ||
Да, можно это обойти, но зачем если и так уже всё работает? |
| Автор: bilbobagginz 29.11.2007, 08:23 | ||
масштабирование - это планирование на будущее: если ты сейчас погемороешься и настроишь систему к-рая будет тикать 5 лет, вместо ежегодного апгрейда нового svn, то тут имеет место быть экономия ресурсов и эффективность. вот у есть NFS сервер, все расхваливают нфс, так мол прикольно, а у может столько компутеров сидят на этом нфсе, что уже догнали границу, и надо искать другие решения, которые нас бы удовлетворяли. на afs поглядываем, на lustre, и т.д. хотя вроде бы nfs еще работает... а ведь могли изначально настроить openafs cell и не парились бы уже сегодня. мысль просекаем ? |
| Автор: nickless 29.11.2007, 23:39 | ||
Угу  Я что собственно и говорю, взвешиваем за и против (потому что есть что взвешивать - у git и svn практически одинаковых набор фич) и что удобно то и берём. Кстати, а чего мы собственно спорим?  |
| Автор: smartov 2.1.2008, 14:37 |
| Из-за случайного поста тема апнулась. Всегда хотел знать, а кто и когда разрешает конфликты в таких вот распределенных репозиториях. То что там кодеры накодили себе это хорошо, кучу веток понаплодили, а совмещать кто будет? |
| Автор: bilbobagginz 2.1.2008, 16:50 | ||
project manager. как всегда. точнее хозяин репозитария. каждая ветка просматривется, мержится или частично мержится хозяином. просто в git есть много тулзов для удобства этого дела. если сравнивать функционал ( не реализацию ) для кодера, то по функционалу, гит похож на свн, но позволяет локально коммитить, в оффлайне. если принципиально сравнивать, то есть несколько других разниц и в реализации и в инструментарии. |
| Автор: smartov 2.1.2008, 18:25 |
| bilbobagginz, Ясно. Ну в обшем то я так и думал что оно именно так. Сочувствую тому самому PM или хозяину репозитория |
| Автор: powerfox 12.3.2008, 23:40 | ||
| По теме: http://alumnit.ca/~apenwarr/log/?m=200801#31 Ссылка на лекцию Торвальдса: http://www.youtube.com/watch?v=4XpnKHJAok8 Начал хакать с помощью гита... Это вещь!!! Я очень и очень быстро (минут за 7, наверное) на Celeron M 1.6 c 1 Гб памяти сделал свою ветку мозиллы, чтобы потестить чужой патч. А там файлов до фига! Исходники + объектные файлы. Ветки мержаться без проблем. Причём всё удобно. Так я не хакал много. А в случае:
К тому же столкнулся с ситуацией, когда хотят заCVSить патчи, которые, возможно, будут убраны. Лишь с тем, чтобы у переводчиков была лишняя неделя (а то и 2-3) для тестов. А гит бы решил эту проблему... И главная ветка бы не получила порцию «дури». |
| Автор: JackYF 13.3.2008, 21:29 | ||
Кто/что мешает коммитить не в trunk, а в branches? Главная ветка не тронута, тестируй сколько угодно. Оттестировал - мержи. |
| Автор: powerfox 13.3.2008, 23:20 | ||
Накладные проблемы и т.д. Никто не станет создавать отдельную ветку ради 1 патча. Я ещё не полностью въехал в DVCS. Но Линус говорил об этом. |
| Автор: JackYF 14.3.2008, 13:33 | ||
да-а? то есть то, что ты создавал 7 минут свой отпечаток репозитория - нормально. А ветку жалко, да? Да и потом. Если надо всего лишь 1 патч - нафиг тогда ветка - слил, действительно, последнюю ревизию себе, у себя проверил, доложился. |
| Автор: kamre 30.3.2008, 07:20 |
| Посмотрел выступление Линуса. Вот такие преимущества DVCS он называл: - offline working: т.е. когда нет доступа в сеть (к главному репозиторию) можно продолжать работать: смотреть историю, коммитить,... - branching and merging: всякий локальный репозиторий фактически является веткой (по отношению к любому другому), возможно слияние с другим репозиторием с сохранением полной истории изменений из обоих, что позволяет постоянно держать локальную ветку в актуальном состоянии; в отличии от веток в централизованных системах локальные изменения никто не видит до той поры, когда нужно протащить изменения в другой репозиторий; - commit access: нет проблемы с выбором тех, кому позволено коммитить в репозиторий, т.к. фактически у каждого свой личный репозиторий (особенно для open source проектов актуально); - strict commiting rule: почти всегда, чтобы закоммитить код, нужно его сначала хорошо оттестировать; получается, что невозможно коммитить малые изменения, логически связанные куски, а вместо этого происходит допиливание кода до приемлемого состояния и затем делается один большой коммит, в котором потом будет сложно разобраться; - network of trust: основной разработчик (project leader, maintainer,...) работает непосредственно с несколькими другими, которым он доверяет; изменения он берет только у них, а они в свою очередь таким же образом работают; когда возникают кофликты при слиянии изменений, то их не обязательно разрешать основному разработчику, синхронизацию могут делать непосредственно те, кто вносил изменения, приведшие к конфликту (nobody is special); - performance, так как весь репозиторий существует локально и нет необходимости что-то пересылать по сети, то все работает очень быстро; например, полное сравнение рабочей копии исходников с любой версией в репозитории происходит очень быстро даже когда в проекте тысячи файлов; - consistency check (security): все ревизии подписаны SHA1 и проверяются при работе с файлами; если известна подпись ревизии, то вся история изменения вплоть до этой ревизии может быть получена из любого источника и можно быть уверенным, что никто ничего не подменил. |
| Автор: JackYF 30.3.2008, 12:11 |
| kamre, спасибо, добротный обзор |
| Автор: powerfox 31.3.2008, 11:11 |
| http://video.google.com/videoplay?docid=-7724296011317502612 О меркулар. Оффтоп, но интересное видео. Посмотреть в спокойной обстановке не смог, пересмотрю на выходных. |
| Автор: Lazin 31.3.2008, 11:49 |
| для mercurial есть клиент под винду - tortoisehg |
| Автор: belonesox 3.5.2009, 13:04 | ||
Для тех кто не осилил этот доклад (лень/долго смотреть/не идет английский на слух) предлагаю http://lib.custis.ru/index.php/%D0%9B%D0%B8%D0%BD%D1%83%D1%81_%D0%A2%D0%BE%D1%80%D0%B2%D0%B0%D0%BB%D1%8C%D0%B4%D1%81_%D0%BE_GIT_%D0%BD%D0%B0_Google_Talks (по переводу — претензии мне) доклада вместе с слайдами и другими кадрами видео. Посмотрите/проникнитесь/посмейтесь… |