Открыть список
Как стать автором
Обновить

Комментарии 61

кто-то нереально постарался с визуализацией
по eclipse hd video на vimeo пережато
Угу. Это игрушка настолько интересна, что я думаю даже попробовать использовать ее как часть отчета по проекту :)
НЛО прилетело и опубликовало эту надпись здесь
юзаю и git и bazaar
больше нравиться второй
привычнее и понятнее после svn
проблем с ним меньше
git он более тяжелый, но далеко не все что он умеет реально полезно
Я хочу в итоге на чем-нибудь распределенном остановиться… Но чтоб принять решение окончательно — ешл еще попробовать надо будет.
Они вроде все распределенные?
Вопрос: для чего вам эта распределенность? Как вы ее планируете использовать?
И насколько она важна среди других фич, таких как: поддержка ИДЕ, интеграция с багтракерами и пр.?
Очень сильно советую Вам посмотреть www.youtube.com/watch?v=4XpnKHJAok8. Создатель GIT доходчиво, в течение часа рассказывает для чего эта распределенность, почему она настолько важна и почему так плохо ее не ценить =)
Посмотрю.
А Вы можете в 2 словах за 5 минут рассказать, что именно Вам она дает?
Пока на Хабре я видел только один аргумент за распределенность и его можно обрисовать так: «Вот представьте, отдыхаете вы на Багамах с прекрасной девушкой. И тут вам приспичило поработать, вы достаете ноут и фигачите-фигачите внутренние коммиты, т.к. интернет дорогой».
В остальных случаях лучше коммитить в общий репозиторий, чтобы другие разработчики могли видеть ваши изменения.
НЛО прилетело и опубликовало эту надпись здесь
Линус там обмолвился что одной важной проблеммой которую они решали в процессе создания это бранчевания и мерджинг. Что на больших проектах с большим количеством файлов и коммитеров при использовании svn к примеру приводит к препирательствам «кто будет делать мердж» читай «кому попарится» :) и скажу я вам git эту проблему решает неплохо(добавьте распределенность и вы еще и решаете проблемму с дурацими именами веток :) как то developer1_branch_for_something_20081231). Одно, как сказал кто-то выше, факт — для того что бы его понять надо действительно сменить парадигму мышления с svn-подобного на что-то совершенно новое.

Недавно на айтиблогс один товарищ написал причину по которой он выбрал все же между git и mercural именно первый так это за то что git все же тяжелее :) а точнее сказать — они с меркурал почти одногодки и при этом git имеет больше «ненужных» фичей…
Э, Вас так же с натупающим ;)
НЛО прилетело и опубликовало эту надпись здесь
Дык и я по таким критериям не выбирал… просто сложилось так что git на глаза попался первым.

В указанном мною посте говорилось мол у git поддержка(читай комьюнити) больше… судить не могу так как с использованием mercural не создал еще ни одного репозитория. Но код его читал(благо в питоне понимаю) и действительно доходчиво написано — глаз радует :)
НЛО прилетело и опубликовало эту надпись здесь
> — Нет .svn в каждой директории, а есть .git/.hg только в корне проекта.
Это совершенно технический аспект, лично мне он никак не мешает. Если мне нужно выгрузить чистый код без истории, то я делаю svn export.

>… Как-то так.
Можно использовать ветки. Опять же за счет того, что все вместе думаю будет проще разгребать.

И Вас тоже! :)
НЛО прилетело и опубликовало эту надпись здесь
> Ну мне пару раз приходилось перетаскивать проект с кучей директорий. Замучался ждать, когда все скопируется.
Я так понимаю, у них примерно та же лохматость, только собранная в одной папке :)

> В DVCS это есть бранчи. Бранчевание и мерджинг по сравнению с свн — сказка :))
Да, ручное запоминание номеров ревизий — не гуд.
Но в 1.5 сделали серьезное улучшение.

Вопрос: как у них с инфраструктурой? ИДЕ, багтрахеры и прочее?
НЛО прилетело и опубликовало эту надпись здесь
У git есть git-svn, кроме того уже есть множество нативно поддерживающих git фишечек. В Eclipse и trac есть соотв. плагины.
Есть еще один момент навеянный…
Как известно крупные корпорации такие новшества не сразу воспринимаю, но я читал что к примеру в HP работает такая схема: git у разработчиков. Что-то разработав более или менее осмысленное они пулят все тим лиду в его репозиторий и он это импортит в головной svn репозиторий. Мы тоже так хотим сделать — так как убедить админов сменить привычный в установке subversion на непостижимый git возможности нет… и в этом мы их прекрасно понимаем — сами с усами :) Но развернуть инфраструктуру как в HP абсолютно не составит труда(тем более что разработчикам достаточно неформального ssh доступа на машину с основынем git репозитроием — то есть не надо разворачивать к примеру gitosis)
НЛО прилетело и опубликовало эту надпись здесь
дык и у subversion кажется тоже при желании можно коммитить по ssh. Просто для dvсs — это свойство позволяет вышеописанным способом успешно паразитировать на непоколебимости стандартности svn. У меня даже иногда возникает такое сравнение легких современных альтернатив с паразитами, или в сравнении с svn и ее современниками как динозавры с млекопитающимися :) лирика
НЛО прилетело и опубликовало эту надпись здесь
> Для доступа к git/hg достаточно ssh
SSH это довольно много!
Если у вас есть какая-то удаленная группа разработчиков, которую вы не очень хорошо знаете и доверяете, то давать им SSH врядли захотите.
У svn в этом плане есть преимущество в работе через WebDAV, HTTP.
НЛО прилетело и опубликовало эту надпись здесь
Получается конечный репозиторий все равно на базе svn?
А админов я очень хорошо понимаю: их задача обеспечить надежную и безопасную работу всего комплекса ПО. И какое-то новое непонятное приложение ставить не хочется, пока в нем не разберешься и не убедишься, что все ОК.
НЛО прилетело и опубликовало эту надпись здесь
Да, в малых и средних компаниях используется мало. ПО не просто должно быть хорошим, но и нормально встраиваться в существующую систему и интегрироваться с уже имеющимся.
НЛО прилетело и опубликовало эту надпись здесь
Не пойму где скачать Сode_swarm
Мне показалось, что активнее всего коммитится Базар — график в основном зеленый.
Думаю, что вопрос выбора системы контроля версий гораздо шире самой системы. Хорошо бы к ней иметь развитую инфраструктуру: поддержку в ИДЕ, чтобы не только в консоли смотреть диффы, интеграцию с системами багтракерами и планировщиками типа trac, jira и т.п.
А качество продукта зависит от количества чекинов?
Нет. скорее от общей структурированности. Если посмотреть — тут красное облоко видно что состоит из нескольких кусков каждого из которых имеет достаточно четкую форму. Это говорит о том, что архитектура была продумана изначально и не сильно менялась в процессе развития.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Начиная с версии 1.6.0 никакого срача уже нет.
А как сейчас выглядит git? Я имею в виду то, что у него творится в /usr/bin.

К сожалению быстро проверить не могу — для Windows поставил версию Git-1.6.1-preview20081227, но это, как я понимаю не репрезентативно…

Я постоянно присматриваюсь к git, но поскольку разрабатываю под Windows, особо активно смотреть не получается — уж слишком, как мне кажется, зависимым есть git от философии *NIX.
НЛО прилетело и опубликовало эту надпись здесь
Найди это всё в /usr/bin/ и получи вкусную морковку :)
НЛО прилетело и опубликовало эту надпись здесь
Сказано же, с версии 1.6.0
Ну не только. Полтора года с ними ничего и нельзя было сравнивать.
НЛО прилетело и опубликовало эту надпись здесь
Но там же разговор шёл о словах Линуса. Но впрочем я и сейчас с ним согласен. ;)
Git хорошая система контроля версий, только она очень большая и учить ее сложно: у нее очень большой набор комманд (>150). Еще у нее надо постоянно оптимизировать (repack) репозитории, чтобы они быстро работали и занимали мало места. Допустим на github.com это делают автоматически каждую ночь. Из плюсов надо отметить очень высокую скорость работы, даже выше чем у Mercurial, но только под Linux.

Mercurial отличается легкостью освоения, простотой использования и скоростью. Ошибаются те, кто думает, что Python медленный. На пример, на hg сидит Sun, Java, Netbeans. Особенно разработчики Явы поражались скоростью коммитов при их объеме кода: с svn по полчаса уходило, с hg практически мгновенно.

А на счет качества кода: у hg высокое, а вот у git высокое только у основных модулей, которые написаны на C, а качество команд на bash и perl очень сильно варьируется.

Я рекомендую mercurial: удобнее, лучше кросплатформенность, легкая расширяемость с помощью модулей, ну и последий аргумент — Python.
Как вам Базар?
Тоже распределенный, тоже на питоне.
Не знаю, не пробовал.
Для виндузятников хорошим агрументом ещё будет наличие черепашки: TortoiseHg Хотя недавно появилась очень-очень сырая версия TortoiseGit
Ну, виндузятники тоже разные бывают… Меня вот, например, от слов «интеграция с эксплорером» малость подташнивает ;)
* Очень просто перейти с svn на git воспользовавшись git.or.cz/course/svn.html
* Основных комманд ровно столько же сколько и в svn + pull/push
* Оптимизация актуально только в *очень* больших объемах, для рядового проекта это излишне.
ещё один голос за меркуриал.

Аргументы примерно те-же. Нет срача в /usr/bin, быстро работает, легко разворачивать репозитории, Python
-1 аргумент :)
это я про срач в /usr/bin/ если что
У git разворачивание репозитория заключается git init, куда проще?
Видимо, он имел в виду возможность удалённого доступа, git daemon, скорее всего.
github.com и счастья полные штаны… чего жизнь себе осложнять
Неправильный у вас подход к делу.
> Рост Git куда как симпатичнее выглядит. Я думаю что там и код получается чище-лучше

Хехе, стоит только почитать тот код. В гите это порядочное месиво, на самом-то деле.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.