git и svn

Про git не знаю, но успешно юзаю для себя mercurial. По сути - почти то же самое. Только умеет работат на удалённых носителях (sshfs, ftpfs), за что и была выбрана.

...

А так - уже много раз говорил. Вопреки расхожему мнению, по-прежнему считаю, что распределённые VCS хороши для индивидуальной разработки в сложных условиях или для работы _высококвалифицированной_ команды разработчиков. Для среднего же разработчика - только SVN. Распределённая же система только создаст головную боль и бардак :)

Нет. git-svn работает просто отлично

ну чтобы перевести на VCS с таким страшным названием (это я про mercurial) пару бригад, в которых есть люди, которые вообще с трудом понимают что такое VCS и которые поклоняются SVN'у нужно много весомых аргументов. Про гит уже немного таких есть, но я хочу не красноглазить, а попробовать для начала.

зачем git когда есть hg?

> зачем git когда есть hg?

зачем git и hg когда есть darcs?

Этот ваш даркс до сих пор тормоз

> Распределённая же система только создаст головную боль и бардак :)

Почему? Проблемы с правами доступа?

>> Распределённая же система только создаст головную боль и бардак :)

> Почему? Проблемы с правами доступа?

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

По теме: вместо Git лучше использовать Mercurial, особенно если есть "люди, которые вообще с трудом понимают что такое VCS".

P.S. Сам осознанно мигрировал с SVN именно на Mercurial.

а можно, плиз, подробней, именно из личного опыта что именно сильно порадовало?

> а можно, плиз, подробней, именно из личного опыта что именно сильно порадовало?

Насчет "сильно порадовало" - это преувеличение, тогда (3 года назад) Mercurial был единственной юзабельной системой. Впрочем, он и сегодня самый юзабельный из всех.

Ничего лишнего, но есть всё, что нужно (в раннем Git юниксвей был доведен до абсурда, а его концепцию индекса я до сих не понял %)); плагин mq (уже давно не представляю, как люди без него обходятся :)); похожесть на SVN с точки зрения CLI (я пользовался SVN с 0.14 по 1.2.x). Сейчас для Mercurial есть еще и неплохая документация документация (http://hgbook.red-bean.com). Собственно, у Git есть два преимущества перед Mercurial - пиар и двухсторонняя синхронизация с SVN.

Ну в кому-то могут пригодиться TortoiseHg и инструменты оттуда, плагин для Eclipse.

> (в раннем Git юниксвей был доведен до абсурда, а его концепцию индекса я до сих не понял %))

да просто там всё с концепцией индекса. Это вроде tagfs, там блобы хранятся в хешах, ключ=хеш от содержимого блоба. А индекс=каталог = хеш от хешей этих блобов. Как к файлам в каталогах можно навесить теги и общюю категорию. Соотвественно, кеш этого каталога надо обновлять (индекс).
UI (CLI) у GIT конечно зубодробильный, 150 комманд -- это чересчур :) Но в общем работает, своё дело делает. Хотя ощущение конечно есть, что делалось это для робатов (или построения нереляционных "БД"), а не человеков.

> Про гит уже немного таких есть, но я хочу не красноглазить, а попробовать для начала.

дык возьми и попробуй. Везде где переходили с CVS/SVN на git это делали после прикидок "а что это даст","а какие скрипты в инфраструктуре ещё надо переписать", "а как сохранить аналогичный прозрачный интерфейс с инфраструктурой". Можно например Кейта Паккарда почитать, как он x.org переводил. "Просто через какое-то время вдруг выяснилось, что мы уже активно пользуемся git, все вопросы снялись, и почуствовали разницу".

Возьми для начала свой девелоперский бранч, порезвись там. обновлять его в git, а его в ствол через SVN. Потом git-svn. Потом освой rebase и cherry-picking. Потом покажи другим, которых "уже немного таких есть". А потом с очередного релиза (менять посреди релиза вроде как не надо) выяснится, что уже активно используется git, а SVN -- не нужен.

Репозиторий бекапить регулярно надо, на всякий случай, по-любому. А если есть бекап, то что останавливает от "экспериментов"?

> блобы хранятся в хешах,

Плакал. Анонимный брат, я верю, что ты понимаешь gitfs до мелочей, но "блобы храняться в хешах" - это со всех сторон шедевр :)

> А индекс=каталог = хеш от хешей этих блобов. Как к файлам в каталогах можно навесить теги и общюю категорию. Соотвественно, кеш этого каталога надо обновлять (индекс).

Monotone, Git и Mercurial очень похожи, но Monotone и Mercurial как-то обходятся без индекса. Да вообще _все_ обходятся без индекса и уж точно не публикуют команды для манипуляции им. Так еще раз - нахрена^Wзачем он таки нужен?

> Хотя ощущение конечно есть, что делалось это для робатов

Ящитаю, Git написали инопланетяне для проведения отбора среди населения Земли %)

>Плакал.

s/REPL>(*)/в хеш-таблицах/ :)

> Так еще раз - нахрена^Wзачем он таки нужен?

исторически так повелось :)
вот появится какая-то ФС с тегами, а индекс в git уже есть ;)
"дохлая ворона.. нэ пригадиилаась" :))

>Ящитаю, Git написали инопланетяне для проведения отбора среди населения Земли %)

Линус -- засланец? Ты знал!!111 :)

> Ящитаю, Git написали инопланетяне для проведения отбора среди населения Земли %)

Oga. Lisp & Git nashe fse.

-- WBR, Aliens.

Одним из последних на fd.o перетащил свой проект на git. До сих пор ломка продолжается, каждый день узнаю что-то новое;) Как просто было жить в мире CVS(SVN)...

> -- WBR, Aliens.

Обратитесь в территориальное отделение MIB - вам помогут.

> которые вообще с трудом понимают что такое VCS и которые поклоняются SVN'у нужно много весомых аргументов.

VCS - version control system - общее название.
SVN - частное название системы контроля версий.

Так что не могу уловить смысл вашего высказывания.

> Распределенные системы объективно сложнее и требуют большей дисциплины

Можно пример в чём сложность? Можно даже на абстрактном примере, не обязательно про git.

Я у git кроме clone/push/pull/commit/branch/tag/fsck/gc комманд не знаю, но мне их хватает :).

> Можно пример в чём сложность? Можно даже на абстрактном примере

Обязательный merge там, где в SVN не нужно ничего или максимум svn up (это на самом деле имеет далеко идущие последствия - граф ревизий нужно держать в хорошей форме); одно и то же изменение может стать разными коммитами; нельзя исправить log-мессагу коммита, поэтому надо стараться сделать всё правильно с первого раза.

Ну а если пользоваться вещами типа mq (в Mercurial) и stg/rebase (в Git), это отдельная can of worms.

> Я у git кроме clone/push/pull/commit/branch/tag/fsck/gc комманд не знаю, но мне их хватает :).

Что, даже diff не знаешь? %) Судя по отсуствию в списке merge, rebase и bisect, ты работаешь сольно и используешь Git в режиме "модная SVN"?

> Что, даже diff не знаешь? %)

diff, log, bisect, merge итп простые вещи забыл указать. Зачем нужен rebase пока понять не могу. Как только оно стало удовлетворять моим нуждам я забросил его изучение :)

> ты работаешь сольно и используешь Git в режиме "модная SVN"?

да, поэтому интересно что ожидает впереди в групповухе :). Щас я девелопер-позер, вроде что-то пишу, но мало кому показываю :).