Даже не представляю, кому это понадобится.
Я думаю, к примеру, тем, кто сомневается, что выбрать: hg или git. Такой сервис может сделать переход между этими системами намного менее болезненным
… и тем, у кого есть лишние 25$ в месяц
Jira тоже не бесплатна, а покупают же!
У Jira есть некая волшебная лицензия «10$ за 10 пользователей» — так что если ставить на свой сервер то это для небольших команд по факту бесплатно — дешевле кружки сейчас, увы, даже не очень хорошего пива. Версия, хостящаяся у них будет уже 10$ в месяц — но это тоже за 10 пользователей и в целом фаально недорого.
Как правило даже в небольшой софтверной конторе кол-во человек больше 10. А когда смотрим на цену когда больше 10 человек, то становится интересней. Эта цифра выбрана ими не спроста ;)
А для конторы в более чем десять человек, в которой более чем десять человек уже активно пользуются джирой, цина в пару тысячь долларов не кажется такой запредельной :).

Это я не то чтобы джиру рекламирую, хорошие альтернативы есть. Это я к вопросу о популярности. Либеральные лицензии для опен сорса / небольших команд + возможность в полтора клика установить собственный локальный сервер = автовин.
На днях буквально смотрел в очередной раз на ее лицензии, и посчитал, сможем-ли мы вписаться в 10 пользователей. При 4-6 активных разработчиках, 2 тестерах, и 2-4 манагеров, и нескольких сторонних товарищей, которым тоже нужно предоставить доступ хотя-бы для чтения — уже плохо вписываемся. Хотя, конечно, при таком раскладе должны быть деньги на нормальную лицензию… но пока экономим $100 в месяц и пользуемся Redmine.
Джира обычно привносится не усилиями команды разработчиков, а откуда-то из района management'а/начальства, которому надоедает хаос и хочется чуть больше порядка.

Убедить начальство, что отдавать (на коллектив из 10 человек) 90 тысяч рублей в год ради того, чтобы 5 человек могли _НЕ_ учить git/hg будет сложно.
>>а откуда-то из района management'а/начальства
Не всегда и не везде. Иногда и в команде работающей по Agile-практикам, там ребята сами приходят к решению какие им нужны инструменты.

>>_НЕ_ учить git/hg будет сложно
Не в этом дело! Я вот до последнего буду сопротивляться решению юзать git. Потому что пользуясь им в течении полгода понял, что больше такого не хочу. После перехода на Mercurial я понял, что с ним буду работать еще долго, пока в мире систем контроля версий не произойдет очередная революция. Вот скажите мне зачем на работе нужна ситуация, когда несколько человек друг другу доказывают какая CVS лучше?
Просто для понимания: если вы не в замке из слоновой кости обитаетесь, придётся работать и с hg, и c git'ом. Потому что в современной экосистеме разработки часто бывает нужно заслать коммит/pull-реквест в «альтернативную» систему версий, которую точно под вас переделывать не будут.
И зачастую проще базово освоить вторую систему, чем разбираться с нюансами расширений типа hg-git.
45 дней бесплатно должно хватить, чтобы выбрать.
Слабо себе представляю IT компанию, у которой нет лишних $25 на качественный сервис с плюшками, даже если эта плюшка нужна одному разработчику.
Согласен, не зачем сомневаться и давно пора ставить Mercurial.
Как видите холивар начать слишком просто, а на работе надо работать, а не холиварить. Если Klin будет прозрачным как для лагеря Git, так и для лагеря Mercurial, то это реально круто!
Адепты git весьма пассионарны, к сожалению. А тем, кто задумывается над адекватностью своих инстументов, было бы весьма полезно внимательно прочитать статью с техническими подробностями и подумать, какое из отображений было сделать проще и почему. И еще подумать, почему пользователи mercurial довольно редко используют букмарки.
У адептов git есть мощный аргумент в виде github.
Ну, я за них рад, правда. Гитхаб не поддерживает бесплатные приватные репозитории, поэтому рассматриваться как конкурент bitbucket-у может только в некоторых ситуациях. По сути для коммерческого проекта в обоих случаях (hg и git) реальный инструмент один и тот же — bitbucket. Ну а в остальном отличаются они (github и bitbucket) друг от друга не очень значительно и чем дальше, тем меньше.
Ну как сказать, что только один. Допустим фирма делает коммерческий форк свободного проекта хостящегося на гитхабе и время от времени посылает багфиксы. Затраты на аккаунт гитхаба могут быть сильно меньше необходимости интегрировать две системы (вернее четыре даже). Или библиотеку/фреймворк, хостящиеся на гитхабе может использовать.

Да и субъективно, как человек, у которого постоянно открыты и битбакет (и часть репозиториев на гит) и гитхаб, могу сказать, что гитхаб по функциональности превосходит битбакет, хотя hg нравится больше чем git. Но для закрытых эксперимнтов в последнее время все чаще стал использовать репы гит на битбакете именно из-за вопросов интеграции с интересующими открытыми проектами.
Ну да, сценарии, когда выгоднее использовать github, придумать можно. Непонятно только, насколько часто они реализуются, такие сценарии. По моему опыту в коммерческих проектах хорошо, если не начнут насиловать SVN-ом с особым цинизмом. А уж до тонкостей преимуществ github-а тем разработчикам как-то вообще фиолетово обычно, им ветки создавать, пушить изменения и писать нормальные комментарии и то лень.
Для значительной части применений проигрывает как mercurial, так и git — так что для новых проектов, если нет специфический задач вроде содержания в репозитории терабайт графики, применять subversion бессмысленно. Удел subversion — legacy и спецкейсы, где мы вынуждены использовать клиент-серверную архитектуру.
Вообще-то проект называется Kiln (а не Klin) Harmony
До сих пор не поправлено, даже в ссылках так (yawn).
UPD: Даже в тэгах (facepalm)
НЛО прилетело и оставило эту надпись здесь.
Только зарегистрированные пользователи могут оставлять комментарии.
Войдите, пожалуйста.