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

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