Я с cvs никогда не работал. Работал с СlearCase и Subversion (svn). До сегодняшнего дня субвершна хватало вполне. Но вдруг понадобилось сделать такую схему:
repo => [checkout1, co2, co3 => [co4, co5, co6] ]
Т.е. так, чтобы рабочая копия на одной машине была репозиторием для другой. Иными словами, понадобились remote branches. В сабвершне все ветки лежат в одном, центральном репозитории. Мне же нужно было построить цепочку (по соображениям гибкости администрирования и безопасности).
В итоге, наткнулся на две чудо-системы: Git и Mercurial (он же hg). Обе работают так: каждый чекаут — это клонирование всего репозитория, что эквивалентно созданию удаленной ветки. Соответственно, можно делать чекаут из этой ветки и коммит в нее же. Но есть еще одна приятная мелочь. Поскольку чекаут — это репозиторий, со своей историей, то даже, работая по классической схеме с одним Главным Репозиторием, можно делать мини-коммиты *на локальной машине*. Это достоинство очевидно, если вы хоть раз работали в команде с соблюдением Zero Bug Principle. В этом случае, вы не можете делать коммит, если какие-либо тесты не проходят. Но бывает так, что вы экспериментируете с чем-то и не занимаетесь проверкой всех тестов, а делать засечки очень бы хотелось… В этих системах такое возможно. Все коммиты идут в локальные копии, пока вы не сделаете коммит на главный сервер.
Волшебно. Но пока я не выбрал, в какой репозиторий съезжать. Сжатая информация по ним такая:
1) Гит работает только на линуксе и маке, поэтому у коллег с виндоусами будут проблемы.
2) Ртуть (mercurial, hg) работает везде, но не имеет системы внутренних бранчей (что мне никогда не было нужно, локальные коммиты покрывают оставшиеся 5% требований). Плюс, гидраргирум вроде как менее проверенный и стабильный. Но это не пугает, т.к., если репозиторий накроется медным тазом, его всегда можно восстановить из рабочей копии.
Пожалуй, выберу ртуть, если будет быстрый и простой импорт из svn.
А что посоветуете вы?
8 октября 2007 в 9:01
Поздравляю!
8 октября 2007 в 1:05
Короче говоря, теперь я не единственный разработчик на своей поляне. Плюс rsync показал, что великолепно умеет перезаписывать серверо-зависимые конфиги (лажащие в репе по особым на то причинам), что, мягко говоря, не годится. Поэтому версионный контроль того, что на серверах разложено, нужен. Из-за наличия двух датацентров, нужны распределенные репозитории.
В итоге, разобрался с git и развернул репозитории. Пока — быстро и удобно. Посмотрим, что будет дальше.
27 сентября 2007 в 1:03
често говоря, недружелюбности в svn я не заметил: любое действие в нем имеет соответствующий уровень сложности: простые вещи делать примитивно, сложные — чуть больше лапами клавиатуру топтать, чем для простых действий, но, тем не менее, все действия вполне обоснованы и лишних телодвижений не требует. Распределенные системы, вообще, — рай для разработчика, тут он получается отвязан от ненадежности серверов и коннекта и может производить с кодом многие спорные действия, не ломая фнкциональность другим и себе, они полностью снимают головную боль типа "я сейчас проделаю с кодом нечто сомнительное, надо не забыть забекапится", а особенно "ой, что я напахал, а забекапить перед этим забыл или не смог, теперь прийдется все назад чинить…" и т.п.
27 сентября 2007 в 1:02
Версионный контроль полезен по многих причинам, в этом я уже убеждался не раз, особенно, когда над проектом работают от дестяков до тысяч человек: тогда без версионного контроля жизнь разработчика вообще была бы адом. Но даже, когда начиная от одного человека работает над проектом, и то нужны: для слежения за изменениями, экпериментов, понимания через н-ное время, откуда в коде появился тот или иной кусок, нужен ли он и зачем.
27 сентября 2007 в 0:03
Про svk тоже слышал. Доки покурю на досуге. Но для текущих задач rsync хватает (серверы-то пассивные, там не девелоперы сидят).
27 сентября 2007 в 0:03
Я вообще не очень понимаю, зачем нужен svn, и более навороченные git/bazaar. Сам с ними знаком (в большей степени с svn), вещь довольно недружелюбная: отнимает время, а гибкости не добавляет. Мы работаем просто с rsync и довольны.
26 сентября 2007 в 23:04
git требует для работы предварительного "курения" доки, иначе, без понимания как он работает, не получится с ним дружить: распределенные системы вносят дополнительный уровень сложности в расплату за гибкость, но они этого стоят: главное — понять, а потом даже очень нравится
Рекомендую //eagain.net/articles/git-for-computer-scientists/ , //www.kernel.org/pub/software/scm/git/docs/core... и //www.kernel.org/pub/software/scm/git/docs/user...
Главное, понять устройство, дальше все манипуляции делать относительно несложно.
Есть распределенная система, которая базируется на svn, называется svk, но я ее не пользовал, поэтому сказать ничего не не могу, выглядит она как svn репозитории, которые между собой синхронихируют.
26 сентября 2007 в 3:00
Уроды. Все уроды. Кроме тех, кто делал svn.
0) Mercurial. Не смог импортировать 300 метров. Отпадает.
1) Git. Прекрасно импортировался. Но непонятно, почему после push на сервер, на сервере не получается сделать pull или еще какой апдейт. Вообще непонятно, как обновлять содержимое сервера, если по докам оно не обновляется. Отпадает.
2) Bazaar. Очень долго импортировал репозиторий, и оооооооочень долго делал remote branch. Питон, что поделаешь. Потом, при заливке на сервер выдавал большой еррор о несовместимости форматов репозиториев, хотя бренч сделался нормально. Оказывается apt-get поставил на мак версию 0.18.0, а на сервер — 0.11.0. При этом на сайте лежат сорцы 0.90.0, которые на сервере не собираются, хотя все зависимости есть. Бред.
Короче говоря, я решил так: на одном из серверов держу репозиторий svn, для себя и коллег. А копии сорцов раскидываю по машинам из вычекнутой на одной из машин рабочей копии с помощью rsync. Дешево и сердито.
А эти распределенные системы совершенно не user-friendly. Хотя в теории все красиво и удобно.
Вот так.
PS. Нет, я конечно, понимаю, что у меня руки растут из неправильного места. Но с svn и rsync у меня не было проблем никогда, а здесь — фатальные проблемы с каждой из систем. We call it's beta because it's betta than nothin'.
25 сентября 2007 в 3:00
Спасибо! Я как раз столкнулся со странными глюками и откатами при импорте 200-метрового репозитория в Hg, поэтому плюнул на винды и взял Git. Сразу стало видно, где настоящие хакеры работали, а где — пионеры
Торвальдс — молодец, короче.
Базаар не смотрел еще.
25 сентября 2007 в 2:01
обе системы хороши, hg, насколько я знаю, был сделан по мотивам гита, у гита с доступом за файрволом тоже все ок. А что выбрать — дело скорее вкуса. Есть еще bazaar (bzr) — написан на питоне, очень быстро развивается, сделан изачально canonical для своего синаптика, у него недавно бранчей не было, но вроде собирались поправить, были проблемы с быстродействием, но вроде уже поправили. гит — самая быстрая и мощная и всех имхо, вин32: порт нативный на мингв делают (альфа вроде работает), есть порт цигвиновский. hg вроде тоже стабильный и качественный, помедленнее и, вроде бы, менее фичастый. bzr — компактен и имхо самый простой в освоении. Предок их всех, monotone, тоже вполне успешно существует, только был несколько тормозным на крупных репозитариях в свое время, как сейчас — не знаю. Из-за необходимости качественно поддержки разработки под мастдаем файрфокс недавно выбирая scm, выбрала hg, bzr отклонила тогда из-за скорости, но сказали, что сделали это на время, потом опять посмотрят на него, git — из-за слабой на тот момент поддержки виндов.
24 сентября 2007 в 21:02
А вот еще: ртуть работает через HTTP, что серьезно облегчает боль тем, кто сидит за файерволами, не пускающими к "экзотическим портам" (3690 для svn, к примеру).
Что с гитом не знаю пока.
UPD. Гит тоже умеет работать по HTTP.