Не народ, содержательно можно как-то про достоинства и недостатки применения? Мне на первом этапе как-то плохо понятны плюсы и минусы как распределенного хранилища так и централизованного. Может про централизованное я более и менее понимаю а вот про распределенное пока понимаю очень слабо.
Комманнды у него местами не шибко очевидные (особенно уделение remote branch'а при помощи push), но если это освоить, что несложно, то все очень удобно.
> Не народ, содержательно можно как-то про достоинства и недостатки применения? Мне на первом этапе как-то плохо понятны плюсы и минусы как распределенного хранилища так и централизованного.
Ты никогда не работал с VCS вообще? Тогда для тебя лучше распределенная система, ИМХО. Другое дело, что не Git (он сделан инопланетянами для инопланетян и их союзников), а что-то вроде Mercurial.
> Может про централизованное я более и менее понимаю а вот про распределенное пока понимаю очень слабо.
Самое лучшее введение в тему написал Jeff Garzik, но для BitKeeper ;)
> > Может про централизованное я более и менее понимаю а вот про распределенное пока понимаю очень слабо. > даже если ты один работаешь, то с распределенной системой можно легко переключаться с ноутбука на домашний сервер и обратно.
А в случае subversion это сложно? Или я не понял вас?
>Может про централизованное я более и менее понимаю а вот про распределенное пока понимаю очень слабо.
Централизованное. Есть сервер или выделенный каталог. Ты можешь закоммитить туда изменения из рабочего каталога, локально или удалённо или забрать их. Всё.
Распределённое. С каждым рабочим каталогом у тебя есть свой локальный репозиторий. Обычно прямо там же, в скрытом каталоге, например, .hg или .git в корне проекта. Для любого каталога в любой момент можешь сделать отдельный репозиторий. hg init - и у тебя всё готово к работе. Можешь закоммитить туда изменения, откатиться назад и т.п. Кроме этого. Ты можешь взять и пропихнуть изменения, накопившиеся в репозитории в другой репозиторий. Он может быть удалённым, может на твоей же машине где-то в другом каталоге. Точно также можно забрать изменения с другого репозитория и провести до полученного результата апдейт своих рабочих каталогов.
> Ты никогда не работал с VCS вообще? Тогда для тебя лучше распределенная система, ИМХО. Другое дело, что не Git (он сделан инопланетянами для инопланетян и их союзников), а что-то вроде Mercurial.
а сколько ты поработал с каждой из систем?
меркуриал не использовал, а с гитом давно работаю - всё удобно, быстро и никаких проблем нет. чем он такой инопланетный для тебя?
> Сейчас приходится немного иметь дело с Git - его точно написали инопланетяне.
Угу. Один толстый инопланетный тролль :) Ему еще его инопланетный мозг не дает перейти на микроядерность... А вообще согласен, ни разу не очевидный и не понятный, не только интуитивно, интерфейс.
>Т.е. git-подобная дрянь для нищебродов, у которых нет постоянного доступа к сети?
Объясняли же уже не раз основной бонус.
В SVN ты не можешь сохранить промежуточный результат у себя, не выкладывая его на сервер. Т.е. при больших изменениях тебе придётся или коммитить в основной репозиторий недоработки, или подолгу обходиться без коммитов, пока не сделаешь полный цикл работы с доведением и тестированием.
В DVCS ты можешь сколько угодно коммитить/откатывать каждый мелкий чих. И только готовый результат заливать на центральный репозиторий.
> Т.е. при больших изменениях тебе придётся или коммитить в основной репозиторий недоработки, или подолгу обходиться без коммитов, пока не сделаешь полный цикл работы с доведением и тестированием.
Branch и коммить в него сколько угодно. Довел до ума - вливай в trunk. Допилили версию до релиза - клади ее в tags. Зато в любой момент любая версия доступна каждому участнику команды.
Я привык именно к такой схеме работы - в транке всегда лежит актуальная dev-версия _рабочего_ кода, которую можно собрать и запустить - она будет работать. В бранчах - те версии, над которыми работают участники команды - там могут быть и недоделки, и недоработки. Team-лидеру, кстати, удобнее отслеживать активность и результативность каждого участника команды по коммитам в свои бранчи. В тегах релизы.
При этом эта схема гибка и может подстраиваться под любую команду с любым циклом разработки :)
Всё равно это менее удобно. Бранчи - это аналоги Хэдов в том же Mercurial, а не аналоги самостоятельной работы :)
Бранчи - в плане истории изменений отдельная сущность. Ты потом не сведёшь вместе две истории.
...
В общем, я несколько лет работал с SVN и CVS, и уже года полтора, как работаю с Mercurial. Так вот, DVCS намного лучше :)
...
Хотя я раньше тоже был фанатом SVN (по принципу «работает? - ну так не меняй ничего») и перейти на Mercurail меня вынудил факт, что в своё время это была единственная VCS, способная работать на удалённых FS. Скажем, у тебя к удалённому хостингу есть ssh-доступ, но там нет ни svn, ни cvs, ни hg. В случае Mercurial (и сейчас (но не раньше) - с git) просто монтируешь удалённую систему по sshfs и работаешь со своей машины. SVN в этом случае обламывается.
Ну и по-мелочи, ещё большой бонус DVCS, что при наличии двух репозиториев локально (скажем, тестовый девелоперский и тестовый рабочий) обмениваться между ними можно прямо, без привлечения внешнего центрального репозитория.
Главное преимущество распределенной системы (git) заключается в независимости от сервера.
Основные недостатки:
- отсутствие авторизации к отдельным файлам/каталогам;
- невозможность работать с частичной копией репозитория (в плане частичной истории коммитов и в плане частичного содержимого каталогов); пока что каждому приходится делать буквально свой собственный сервер с полным репозиторием и полной историей, даже если нужно изменить всего-лишь один файл.
Достаточно избавится от этих недостатков - и у SVN не останется шансов. Не знаю про git, а у mercurial уже есть какие-то успехи в этом плане.
> Черт возьми, ты победил. Такой нереальной крутости я еще не видел
Вольно, рядовой.
> Branch и коммить в него сколько угодно.
Если у каждого разраба есть по бранчу или более - вы фактически эмулируете работу DVCS...
> В бранчах - те версии, над которыми работают участники команды - там могут быть и недоделки, и недоработки
...с тем недостатком, что у вас история "грязная" - в ней зафиксированы ненужные ошибки (потому что откатить коммит вы не можете, а средства вроде mq для SVN не доведены до ума). Догадаться, чем вредна "грязная" история, остается как упражнение читателю.
Всё остальное, о чем ты сказал, делается в том же Mercurial не сложнее, чем в SVN.