"а мужики-то не знают"...

чем svn г**но? и чем так заруливает git?

тем, что, вот сидишь ты в поезде/самолете/автобусе, едешь домой, с ноутом,
и можешь себе представить вот у тебя гениальная наработка в голове появилась.
ну ты ее начал реализовывать, запудрился, и приехав домой, решил делать по-другому, потому как оригинальный код ты уже изменил до неузнаваемости.
а как было бы хорошо закоммитить несколько раз в пути. правда ?мог бы сделать несколько коммитов в пути, и к ним вернуться ... но сделать этого с svn - нельзя без заморочек:
сервер то не доступен, а рабочая копия не коммитится... вот и облом:
нужно создавать свой репозиторий, в него импортировать твой код, а потом корячиться всю ветку вставлять в основной репозитарий. довольно неудобно.
svn - и в концепции и в реализации основан на централизованном сервере, будь то apache или svnserve.
есть куча - репозитарий, и все в нее кидают лопатой, когда можно.
почему так ? потому что слияние веток настолько неудобно, что никто не хочет много раз его делать.

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

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

кроме того, особое внимание там уделили легкости слияния веток и разделения на них, т.е. merge/branch.
и всё работает побыстрее svn.
ессно kernel.org уже переходит постепенно на git.

всем удачи.

жёсткие аргументы... меня вот только одно интересует: х знает когда появилась cvs, потом не так давно появилась svn, в которой явно постарались убрать недостатки cvs'a... и что, никто не догадался сделать "нормальный" merge/branch? странно это всё. Жалко, я не пробовал, у меня таких задач не стояло.

Но как-нибудь на git надо посмотреть.

P.S. так чего же многие крупные проекты до сих пор используют "неудобные" cvs/svn, неужели они про git не знают? Или, всё-таки, не так уж коряво сделан merge/branch в том же svn?


Можешь объяснить, в чём неудобность? и удобство git'a?

потому что тулзу придумал линус торвалдс совсем недавно - 2 года назад
http://ru.wikipedia.org/wiki/Git
и нет еще родных клиентов по винду (только через cygwin или mingw ), 




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

читай англ. статью:
http://en.wikipedia.org/wiki/Git_(software)

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

вот я юзаю svn. Что у меня криво работает-то? Номер версии у всех файлов один и тот же.

Wtf "визуализация истории"? Всё равно я одними консольными клиентами пользуюсь...

git распределённый, svn нет, у каждого свои достоинства и недостатки, чего спорить то 


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



Это сообщение отредактировал(а) ZeeLax - 27.11.2007, 04:08

Создал тему в религиозных войнах, чтобы здесь не оффтопить 

в клубе по внутренним правилам можно немного культурно пофлеймить.


nickless, с т.з. фирмы - 

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

не правда ли ?

и вообще с т.з. клиента git может изображать из себя и cvs сервер... так, для отвода глаз : )

Да, можно это обойти, но зачем если и так уже всё работает?  

масштабирование - это планирование на будущее: если ты сейчас погемороешься и настроишь систему к-рая будет тикать 5 лет, вместо ежегодного апгрейда нового svn, то тут имеет место быть экономия ресурсов и эффективность.

вот у есть NFS сервер, все расхваливают нфс, так мол прикольно, а у может столько компутеров сидят на этом нфсе, что уже догнали границу, и надо искать другие решения, которые нас бы удовлетворяли. на afs поглядываем, на lustre, и т.д. хотя вроде бы nfs еще работает... 
а ведь могли изначально настроить openafs cell и не парились бы уже сегодня.
мысль просекаем ?

Угу   Я что собственно и говорю, взвешиваем за и против (потому что есть что взвешивать - у git и svn практически одинаковых набор фич) и что удобно то и берём. 

Кстати, а чего мы собственно спорим?  

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

project manager. как всегда. точнее хозяин репозитария.
каждая ветка просматривется, мержится или частично мержится хозяином.
просто в git есть много тулзов для удобства этого дела.
если сравнивать функционал ( не реализацию ) для кодера, 
то по функционалу, гит похож на свн, но позволяет локально коммитить, в оффлайне.
если принципиально сравнивать, то есть несколько других разниц и в реализации и в инструментарии.

bilbobagginz, Ясно. Ну в обшем то я так и думал что оно именно так. 
Сочувствую тому самому PM или хозяину репозитория

По теме:
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) для тестов. А гит бы решил эту проблему... И главная ветка бы не получила порцию «дури».

Кто/что мешает коммитить не в trunk, а в branches? Главная ветка не тронута, тестируй сколько угодно. Оттестировал - мержи.

Накладные проблемы и т.д. Никто не станет создавать отдельную ветку ради 1 патча. 
Я ещё не полностью въехал в DVCS. Но Линус говорил об этом.

да-а? то есть то, что ты создавал 7 минут свой отпечаток репозитория - нормально. А ветку жалко, да?
Да и потом. Если надо всего лишь 1 патч - нафиг тогда ветка - слил, действительно, последнюю ревизию себе, у себя проверил, доложился.

Посмотрел выступление Линуса. Вот такие преимущества 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 и проверяются при работе с файлами; если известна подпись ревизии, то вся история изменения вплоть до этой ревизии может быть получена из любого источника и можно быть уверенным, что никто ничего не подменил.

kamre, спасибо, добротный обзор 

http://video.google.com/videoplay?docid=-7724296011317502612
О меркулар. Оффтоп, но интересное видео. Посмотреть в спокойной обстановке не смог, пересмотрю на выходных.

для mercurial есть клиент под винду - tortoisehg

 Для тех кто не осилил этот доклад (лень/долго смотреть/не идет английский на слух) предлагаю 
перевод-стенограмму  (по переводу — претензии мне) доклада вместе с слайдами и другими кадрами видео. 
Посмотрите/проникнитесь/посмейтесь…