Забавно, кстати: система без будущего имеет максимальное число пользователей… Все читатели Хабрахабра работают в someplace like Google or Apple with loads of IP to protect?
Ну так попробуйте. Какой смысл будет от системы контроля версий если версиями нельзя будет легко обмениваться? Патчи по мылу слать is so last century and plain dumb.
Политика принятия патчей у разных проектов отличается, и я не особо понимаю как здесь поможет github. Уже был ohloh.net для любителей отразить своё участие, теперь вот ещё один для любителей форков. Может действительно стоит попробовать, хотя у меня на git аллергия, после того как он засрал мне bin кучей файлов и заставил учить кучу новых команд — почему нельзя было сделать так просто как в Mercurial?
Не то, чтобы он круче, просто некоторые идеи перфорса мне в своё время очень понравились. Например воркспейсы (clients в терминологии комманд-лайнового p4) — мэппинги директорий в репозитарии на директории на рабочей машине. С их помощью можно отфильтровать нужный набор исходников и скрыть то, с чем не работаешь. С версии 1.5 svn начал поддерживать отслеживание мержей и списки изменений, когда я знакомился с перфорсом, он этого не умел, поэтому перфорс меня впечатлил. Да и сейчас, надо сказать, мерж и списки изменений в svn довольно убоги по сравнению с перфорсом, особенно мерж. Blame тоже в Perforce Visual Client реализован намного удобнее, чем в черепашке например, хотя это уже сравнение не самих VCS, а их клиентов.
Забыл, у них отличная интеграция в Visual Studio. Про Visual SVN знаю, но у Perforce она нативнее, что-ли. Например VisualSVN для показа измененных файлов вызывает черепашье окно Check for modifications, а Perforce отображает всё в окне студии Pending checkins.
Кому нужно? Если вам нужно выбрать VCS и вы решили переложить этот выбор на хабрачитателей, то вы поступили неправильно, как мне кажется. Ибо выбор VCS делается исходя из каких-то требований и, возможно, ограничений, а ставить то, что стоит у большинства — можно и не угадать.
Я думаю большинство использует сразу несколько систем. Поэтому интересовало именно предпочтение. Согласен, что ставить то что у большинства — не самый оптимальный вариант.
Ещё есть такой параметр как скорость работы
по основному функционалу они все почти равны, а вот скорость различается, так svn медленнее чем например тот же git
зависит от политики сабмита. Если условно говоря, один день — один changelist, то непринципиально. А если раз в десять минут commit (на каждую сделанную хреньку), то очень принципиально. git как раз приучает к тому, чтобы коммитить часто. Это дает и более удобный способ отката, и более точный bissect при поиске места, где был появилась ошибка.
Частые коммиты => частый прогон тестов и билд продукта. Может быть на каких-то простых проектах это и реально. На сложных коммитить каждые 5 минут накладно.
Если взять тот же git, у каждого разработчика есть свой репозитарий и коммит идет туда (условно — раз в пять минут). Есть основной репозитарий, куда коммит идет значительно реже (один-два раза в день). Тесты гоняются только на коммитах в основной репозитарий.
Очень интересно, а почему хотите перейти с hg на git? Я просто сейчас как раз рассматриваю разные варианты, на какую систему перейти, и hg вроде как выглядит более привлекательным. Наши особенности — большой проект (размер cvs репозитория — 700 Мб, размер головы — 134 Мб, ~6000 java-файлов + некоторое количество бинарников), много бранчей (40 штук), нужно работать как на Linux, так и на Windows.
Переходите на hg, можете почитать конкурсы Sun(OpenJDK, Solaris, Netbeans), Mozilla — почему они выбрали Mercurial среди других DVCS. Ну и учитывая, что вы работаете с Java шансов следовательно больше с hg столкнуться, да и на svn она больше похожа в плане интерфейсов.
Да я про плюсы читал, я же написал — склоняюсь как раз к mercurial. Интересно как раз, какие могут быть причины перехода с hg на git — потому что я по описаниям и обзорам таковых не обнаружил (разве что кроме того, что git делает Линус Торвальдс %-)).
Выбор пал на hg вместо svn так как он DVCS и более friendly, чем git. Но сейчас я хочу перейти на git, основываясь на мнениях авторитетных для меня людей, они производили сравнения что-то искали и нашли это в git; но для меня является аргументом их слово, им я верю. Разумных аргументов привести не могу, для вашей задачи могу посоветовать попробывать обе системы и самому выбрать.
Разумеется, я пробую и то и другое перед окончательным выбором, и, разумеется, выберу сам и ни в коем случае не перевешиваю проблему выбора VCS под наши задачи на вас или на кого-либо ещё :-)
Но тем не менее, даже несколько дней опробования системы не покажут всех нюансов, поэтому можно попросить вас узнать у этих авторитетных людей, какое преимущество git они имели в виду (то самое, что они искали и нашли в git)?
Видимо, Вы не правильно трактуете это выражение… Оно значит, что когда уже хорошо, то стремлением к лучшему можно все испортить: «и осталась старуха у разбитого корыта»
Мы как-то пытались внедрить Visual SourceSafe, но он так медленно работал и жрал кучу трафика. Поэтому мы от него отказались. Сейчас перешли на SVN и очень довольны. Нас он вполне устраивает.
Ребята, этот пост очень вовремя! Помогите ламеру, очень прошу!
Постановка такая — у нас в компании основное, над чем ведётся работа это офисные документы в Ворде, Ёкселе, Проджекте и Визио: техзадания, планы, отчёты, статистические данные и так далее. Над одним документом могут работать несколько человек. Требуется система версионирования, которая бы позволяла это делать, в том числе через Интернет, и была бы достаточно защищённой. И желательно бесплатной.
Классно интегрируется с VS, хотя Visual SorceSafe это делает не хуже. Но он также tool для управления самими проектами(интеграция с MS Project), колибрацией и репортами проектов.
Как и подавляющее большинство продуктов Microsoft, TFS может похвастаться отличной интегрируемостью, расширяемостью и удобством. Контроль версий — это лишь одна из возможностей TFS. Но в разработке ПО для обеспечения процесса разработки необходимы и другие сервисы. TFS как раз и представляет собой такое комплексное решение. При этом TFS — это не какой-то разрозненный набор программулек, а интегрированная система, которая включает в себя лучшие инструменты («а мы просто используем TFS»), и несмотря на некоторую громоздкость, это очень гибкая система.
Нет, я профессиональный разработчик, который успел за свою жизнь поработать и со старым Source Safe, и с современным TFS, и с CVS/SVN, и даже с таким раритетом как MKS. Поэтому могу сравнивать и рассуждать.
К слову, сейчас я работаю в основном с TFS, а SVN использую исключительно для доступа к опубликованным open-source проектам.
Subversion, возможно, и не самая передовая VCS, но мы остановились на ней потому что: её функционала нам хватает с головой, интеграцию с ней имеет практически любой софт (Trac, Eclipse — используемое нами).
Думаю, кто хоть раз всерьёз использовал Perforce, не захочет больше ничего. Perforce — шедевр простоты использования вкупе с невероятно красивой логикой. На работе вынужден использовать Subversion, дома — Perforce. Кстати, дома его можно использовать совершенно легально (2 клиента и 5 workspaces — не требуют денег).
Если буду перечислять детали, мне тут, наверное, скажут, что есть это и в других системах. Поэтому отвечу я образно, хоть и будет это несколько голословно на вид.
В Perforce, и его клиентских программах, чувствуется академический подход и забота о пользователях, которая присутствует только в тех системах, которые разрабатывались не кучкой дерзких программистов, думающих о своих проблемах, но командой архитекторов, которые ставили целостность системы и её детальное проектирование, под основные нужды пользователя, в центре своего внимания. Вместе с тем, присутствует там и аскетизм, и самодостаточность, которые рождаются только в самых продуманных системах. Perforce удобен для постижения даже не программистом, поскольку сценарии работы с ним естественны природе: взял файл на редактирование, отредактировал, отправил. Удобен он и для разработчиков, поскольку позволяет просто создавать метки, брэнчи, интегрировать, отслеживать ревизии и сравнивать изменения. Всё это имеет очень простой консольный интерфейс. Всё это можно подытожить простотой установки и администрирования сервера. О надёжности ходят легенды. :)
Но, как ни крути, наверное дело личных предпочтений каждого это. Я вообще отказался от хранения файлов, с которыми работаю, в файловой системе. Поскольку удобно использовать мне перфорс и спокойно мне от ощущения того, что смогу проследить я всю историю затем, а в случае краха системы, есть у меня резервные копии. Был бы рад я, если бы какой-нибудь Гугл сдавал место на своих серверах для хранения своих файлов подобным образом, потому как положил быя туда всё, что дорого мне, и возможно должно пережить меня. :)
По работе использую Git — тихий ужас просто, пока выучишь все тонкости — состаришься. Для своих целей использую subversion, что и другим желаю, хотя Mercurial тоже балуюсь.
Даже не знаю с чего начать. Ну начну с того, что интерфейс Git — жутко неотесан. Я использую как git bash так и tortoisegit, и в обеих случаях результат оставляет желать лучшего. Например в git bash помимо того что есть сотня команд которые нужно знать наизусть (я лишь помню push/pull/commit), так еще комманды названы настолько неинтуитивно, что новых пользователей нужно отсылать в документы чтобы они разбирались что делает git remote origin master и прочие аналоги. В subversion такого безобразия нет, там разработчик сразу понимает что есть commit и update.
Визуальный интерфейс Git соответствует ситуации «смотрю в книгу вижу фигу» — думаю что любой из разработчиков кто совался в UI поставляемый с TortiouseGit либо забил сразу же, либо пробовал и потом долго плевался. UI неполон (иногда правильно закомитить из него попросту невозможно) и жутко неинтуитивен. Лично я не пробую даже.
Ну и еще забыл добавить что интеграции с VS нет, что очень сильно напрягает по сравнению с тем же AnkhSVN и Mercurial.
Не, работа — чистый дотнет и винда. Что касается «можно прописать» это все архаизм — система должна сама знать что и как. Если мне приходится редактировать конфиг (а мой гитовский конфиг огромен), по это значит что система мешает разработчикам писать ПО, отвлекая на всякие ненужности.
Кстати, не только проекты, но и все файлы и документы, которые имеют хоть небольшой срок жизни: домашняя бухгалтерия, планы, mind maps, черновики и заметки — всё это прекрасно дружит с перфорсом. И удобно, если дома есть локальная сеть, нет привязки к компьютеру и решается проблема синхронизации. Просто сказка.
Ваш выбор системы управления версиями?