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

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

Ежегодный осенний подсчет цыплят (2010, 2009). Суть и порядок ответов не меняю, чтоб не влиять на тенденцию, поэтому в сложных случаях (hg-svn, git-svn) уж выберите то куда чаще делаете коммиты :)
на данный момент можно сказать что наблюдается тенденция к тому что народ начинает переходить на git. Так то прикольно потом за лет так 10 срез этого опроса посмотреть.
Предсказуемо, что svn…
Но уже меньше. -7% по сравнению с 2010 и -11% по сравнению с 2009 (на момент коментария).
Сам проголосовал за git, так как его использую для личных проектов и фриланса, в то время как svn только на работе.
Я правильно понимаю, что svn — это вселенское зло, которое надо искоренять так же как и windows во имя эры linux и git?
Ну не то чтобы зло. Но это представитель прошлого. Перед современными системами у него нет никаких преимуществ. Кроме (спорный вопрос) лучшего инструментария.
Ну так же и у Windows — перед современными системами у него нет никаких преимуществ кроме инструментария (софта под него).
Да брось, виндовс — хорошая система (для отдельных групп пользователей). Но я нахожу что если ты не связан с разработкой под виндовс (дотнет там и прочая), то ты получишь более комфортную жизнь в других системах.

Мой прошлый выбор — убунту. Текущий — макось. :-)
Речь про выбор для разработчика, само собой.
cубъективно это. я пользуюсь и маком и убунтой и виндой. имхо win7 удобней в повседневной жизни
А что насчёт очень толстых проектов?
А что насчет них? Вот ядро линукса — это толстый проект или не очень? :-)
Думаю не очень. Вот какая-нибудь игра с кучей графики, звуков и прочих ресурсов — да. Не у каждого хватит места на харде, чтобы выполнить git clone.
Гит, как и прочие традиционные системы контроля версий, не приспособлен для хранения бинарных файлов. Для этого делают специальные системы.
НЛО прилетело и опубликовало эту надпись здесь
Ну это для бедных :-)
НЛО прилетело и опубликовало эту надпись здесь
Давно хотел узнать — а какие системы лучше использовать для управления именно бинарными файлами?
Есть, но не для программистов. Для нетехнического люда, да еще с не текстовыми документами (художники, к примеру) svn много проще для понимания (хотя бы последовательными номерами ревизий) и подразумевает администрирование репозитория специалистами.
Если Вы под инструментарием подразумеваете TortoiseSvn, то на сегодня TortoiseHg 2.х уже гораздо мощнее.
Я ж и говорю, спорный вопрос. :-)
Я могу в git ограничить доступ к определенному каталогу внутри репозитория? Например разработчику на весь репозиторий дать ro, а на конкретный каталог rw?

Я могу в git сделать clone не всего репозитория а конкретного каталога внутри репозитория?

Для некоторый вещей в git надо делать костыли, когда в svn все гладко.
Для ограничения доступа можно использовать коммит хуки. Так что это полторы вещи, которые в гите делаются менее гладко, чем в свине.

Как по мне, одна только локальная история и легкий бранчинг стоят двух десятков подобных фич :-)
через хуки — костыль.
Каждому свое. Мне как раз важнее те две фичи, что свн умеет.
пока живо зло в лице CVS, и так есть что искоренять
А смысл его искоренять, если svn вполне себе нормально работает и проще в использовании? Для проектов на несколько человек вполне подходит.
Вы хотели сказать привычней?
У нас SVN это страшный сон, git и mercurial наше все:)
А лично у меня незабываемые впечатления в свое время оставил SVN наличием или отсутствием слеша в конце пути репозитория. Как показывает просмотр открытых реп, не у меня одного :)

Сколько знаю людей, освоивших новые системы контроля, никто не хотел вернуться обратно на SVN.

Ну, после того как мне понадобилось выкачать директорию на 30 килобайт из репозитория размером в полгигабайта сидя на полумегабитном канале, я в сторону гита очень косо смотрю. А SVN для текущих нужд хватает за уши.
Ну это да, с этим там плохо.
а через что тянули? там вообще неплохие веб интерфейсы есть, с помощью которых можно вполне неплохо скачать только нужные файлы.
В голом гите ничего этого нет. :-)
Страшный сон — это не svn, а отсутствие какой-либо системы контроля версий вообще.
+1 бывает и такое — знаю не по наслышке ;)
Думаю Git станет еще популярнее, когда доразовьются различные плагины для работы с ним в IDE. На мой взгляд подобный плагин для Netbeans пока еще убог.
Да, пожалуй, ты прав. Раньше я вообще не пользовался никакими гуёвинами. Через консоль было всё удобно. Пока не вышел гитхабовский клиент. Теперь пользуюсь поровну им и консолью.

Встроенными в IDEА средствами пока еще не было нужды пользоваться, даже мешают.
Встроенными в IDEА средствами пока еще не было нужды пользоваться, даже мешают.

сомневаюсь, что в консоли можно реализовать такой же удобный диалог для сравнения и слияния конфликтующих изменений. Удобно просто из IDE быстро посмотреть что менял с последнего коммита, или сделать частичный коммит/роллбак. К тому же позволяет работать с разными VCS, если попался проект на неродная. В общем, я бы посоветовал посмотреть на встроенные средства, мне нравятся.
говорят, в виме есть просто сумасшедшний (в хорошем смысле) инструментарий для диффов/мержей. Но у меня борода слишком мала, для того чтобы им пользоваться. Ну и тьфу-тьфу, мержить приходится нечасто.

А диффы в консоли смотреть вполне себе комфортно.
я вот пользуюсь. особенно рулит conflict resolver. это если не вспоминать про tasks, заинтегрированные со всем, чем можно.
Проработал под Git-ом год, понял что у SVN есть свои отличные прелести
На основной работе svn, а для своих проектов используется Mercurial.
На работе — svn,
свои проекты — и в домашней svn (которыми незачем делиться), и в git на гитхабе (публичные),
всякая мелочь, которая недостойна хранения в рабочем репозитории и при этом не относится к предыдущему пункту — просто в git, локально.
Пытаемся уже год как перейти на git или меркуриал, да всё руки не доходят, да и логи нужно все, диффы переносить как-то. В общем, пока что остаёмся на svn
Здесь сила привычки. Команда большая и всем нужно перенастраиваться итп. Дело не только не в диффах.
Расскажите о плюсах новой системы и пускай все на кошках попробуют
Первые пару недель плеваться будут, а потом — ничего, освоятся и будут предпочитать их SVNу)
Один каталог .git в корне рабочей копии лучше, чем множество .svn в каждом подкаталоге.
НЛО прилетело и опубликовало эту надпись здесь
Пользуюсь TortoiseGit. Стало удобнее, чем TortoiseSVN.
Мы думали о переезде с SVN на GIT порядка 3х месяцев, а потом раз и перешли. Да, по началу были проблемы, связанные с концепцией гита, но это быстро невелировалось плюсами гита. Мы вошли в нормальный ритм примерно за две недели.
Кстати как рекомендация советую подготовить mini-git-workflow, в который на первом этапе стоит добавить только важные моменты, которые пригодятся в 90% случаев, а остальное потом в процессе описать можно — очень помогает в работе. Такой список легко гуглится по запросу «howtogit».
Удачи :)!
Пока svn, но в планах перейти на какую-нибудь DVCS. Больше по душе конечно Bazaar :)
Ага, в том ответе по сути дела-то — «да, всё действительно так плохо, как там написано».
Проголосовал за SVN.
Хотя на новых проектах переходим на Git
Раньше использовал svn, но однажды познакомился с git и теперь на svn даже не смотрю.
Раньше использовал svn, потом познакомился с hg. Еще больше полюбил svn :)
Я бы ещё понял если Git, к нему привыкнуть сложнее. Но Mercurial… Вы что, серьёзно?
Серьезно :)
В то время как очень многие считают СВН деревянным, я считаю его просто легким и без излишков. А в hg (который от git-а принципиально ничем не отличается) слишком уж много всяких наворотов, бантиков и плюшечек.
Это от людей зависит, у нас пол команды любит гит и считает, что в хг всё неправильно, другая половина говорит всё наоборот. Причём у всех есть свои хорошие доводы
Ну я не со зла сказал, мне самому Git больше нравится. Но у Mercurial меньше шансов напортачить в репозитории, по моему опыту. Git всё же чуть более низкоуровневый (что добавляет ему чуть больше возможностей, кстати).
Программисты с git работают.
Художники, дизайнеры с svn :)
Простите за нескромный вопрос, а что художникам и дизайнерам хранить в svn? версии своих файлов?
да комитят туда весь арт по проекту.
Исходники в основном.
Хранится все централизовано и бакапится тоже.
Ага, знал я такие проекты. Там репозитории по 10 гигов весили :-)
даже ближе к 100 :)
Bazaar
осваивается за несколько минут, просто и удобно.
Пользуюсь Git. Комиты в CVS/SVN/VSS
Я ввел и рассказал как работать с git на работе, теперь мы только им пользуемся, правда пришлост некоторое время бегать меж сотрудниками и помогать, но через полгода все привыкли.
Если бы не это, то по старинке бы пользовались svn.
Да-да, я так уже не один коллектив обратил :-)
а я начала обращать, а потом задумалась, а зачем, собственно, если и так неплохо… расскажите, какие у вас доводы? а то хочется гит, но как-то неубедительно для целой команды:)
Я на работе ввёл svn + Redmine (а до этого — svn + Trac).
А до этого по старинке долгие годы работали вообще без багтрекера и системы контроля версий.

Каких-то особых причин переводить людей на git не вижу — у нас и svn-то кроме программистов никто не использует — разве что дизайнеры, которые рядом и которых можно легко агитировать за.
В чем я точно уверен, так что для дизайнеров git — зло.

Для программистов же (субъективно) лучше git или hg, потому что позволяют много чего коммитить, перекоммичивать, откоммичивать обратно перед тем как отсылать в центральный репо. Ветки в svn это действительно жутко неудобно (svn switch долгий, svn merge глупый, svn commit публичный), понимаешь это когда начинаешь работать с гитом. Также за простой git init && git commit -a -m «Start» в любой неверсионнированной папке в которой я хочу что-то поменять я продам родину :)
svn все реже — Mercurial все чаще
Основной проект на SVN. Новое делаю на Git. Возможно, к концу года окончательно на git перееду.
Почему в опросе не чекбоксы? Мы используем и git и Mercurial.
а зачем? Системы похожи, зачем их совмещать??
Потому что сами используем git, а некоторые заказчики (соответственно, и мы тоже) — Mercurial.
git используем, бранчи и стэш это сила.
Вижу, что нет никого, кто использовал бы Стартим.
И правильно делаете, что не используете! Я вот с ним намучился в своё время…
Сейчас svn.
Проголосил за git, хотя несколько проектов до сих пор болтается в Mercurial, ну а с svn ушел уже года 3 как.
Mercurial, но исключительно потому, что на нём работает Bitbucket, а им я пользуюсь, потому что там можно бесплатно создавать закрытые репозитории.

Да, теперь там уже есть поддержка и GIT, но на моей машине GIT настроен для GitHub, а удобного способа жонглировать несколькими аккаунтами я не знаю.
Насчет жонглирования аккаунтами не понял…
Используем SVN, но помимо нее сделал себе скрипты инкрементального копирования через rdiff-backup.

Резервное инкрементальное копирование запускаю перед Commit/Update, чтобы обезопасить себя от вредителей, которые пишут код не в рабочей директории, находящейся под контролем SVN, а в боковой. Эти товарищи держат директорию, в которой работают, где-то в другом месте, а когда нужно синхронизироваться, копируют файлы в рабочую директорию SVN, а потом забирают их.

Проблема в том, что перед синхронизацией им надо вначале запускать синхронизацию рабочей директории, забирать файлы из рабочей директории себе, параллельно посмотрев, изменили ли они сами там что нибудь. Проверить работоспособность, залить в рабочую директорию, засинхронизироваться. Но кто бы это делал! Копируют файлы просто из своей «боковой» директории в рабочую, и синхронизируются.

В результате, новые изменения, которые уже есть на сервере, и залиты до этих деятелей, возвращаются к предыдущему состоянию так как переписываются поверх из устаревших файлов, которые деятели копировали из боковой директории в рабочую (у них же новых изменений нет).

Дело усугубляется тем, что могут скопировать в рабочую директорию каталог с подкаталогом .svn, и тогда начинается максимально жосткая чехорда с изменениями, которые были приняты/потеряны/переписаны более поздней версией.

Вот тут-то приходится расчехлять архив rdiff-backup и смотреть как оно должно быть на предыдущем этапе, когда программа работала хотя бы у меня.
А зачем они держат файлы в соседней папке?
Боятся, что их исходники испортятся коммитами других разработчиков. Доурдом одним словом.
Провести разъяснительную работу. Не поможет — уволить всех. Не можешь — беги оттуда. :-)
Насколько я помню, то (лет пять назад) SVN уже не давал делать коммит, если в репе есть ревизия новее. То есть, затереть свежие изменения можно было лишь обновив локальную копию, а потом скопировать поверх неё файлы из соседней папки.
Если дата файла поменялась, то закоммитится.

> То есть, затереть свежие изменения можно было лишь обновив локальную копию, а потом скопировать поверх неё файлы из соседней папки.

И это тоже делали. На вопрос зачем — «я забыл после обновления скопировать в свою папку изменения».
А зачем они вообще другую папку завели?
Тут даже вопрос «А зачем они вооще SVN пользуются?» если не ведут разработку в рабочей директории.
Работал я в одном большом-большом швейцарском банке. Так там контроль версий был основан на зиповании папочки и откладывании его на сетевую шару.
Мне стоило титанических трудов внедрить туда хотя бы свин :-)
Svn на работе. Свои проекты в hg.
Жутко неудобное и тормозное «Хранилище» 1С. Потому как других вариантов нет.
Всегда есть варианты! Можно устроиться в 1С и написать лучше! :-)
НЛО прилетело и опубликовало эту надпись здесь
Другая бесплатная распределенная VCS: fossil-scm.org/ (+трекер, +wiki на встроенном сервере) — размер 1Мб — от создателя SQLite.
идеальна для микропректов
Мы к fossil'у пришли по пути CVS -> SVN -> monotone -> GIT -> fossil. Git на нашем «микропроекте» тормозил безбожно. Наверное потому, что использовали его под Windows, а не в родной стихии.
Я честно пытался понять философию git, но «не судьба». Пытался и на придуманных проектах познать его мощь, и на корпоративных больших и сложных. Запутался, не увидел никаких преимуществ для себя и команды перед svn-ом.

С удовольствием бы прочёл дельную статью о git: преимущества, основы (по новому кругу), как правильно использовать, в чём фишка распределённого контроля. Может когда-то дорастём до git, но пока выбрал svn.
А ты смотрел то знаменитое выступлени Линуса? Меня именно оно убедило.
Фишка в полном репозитории у каждого, регулярных коммитах без паски сломать транк и постоянных ветвлениях
Сейчас не 2005 год, все это легко гуглится заинтересованным человеком. Вставать в позицию «удивите меня» как-то неконструктивно.
mercurial тоже не?
У меня уникальная ситуация — я использую на работе CVS, TFS 2010 и Mercurial. Первые две люто ненавижу, Mercurial наиболее удобен.
А VSS как же? :-)
Бог миловал.
TFS уже года полтора. В целом, если к нему привыкнуть — довольно удобен.
Mercurial, начал работать с VCS совсем недавно. Сначала пробовал git — не разобрался, потом попробовал SVN — тоже ничего не понял.
А hg достаточно прост.
«Version Control with Subversion» читали?
Она же — «Управление версиями в Subversion» (перевод частичный, в основном переведены начальные главы, где введение и инструкции для пользователей).
Написано достаточно понятно.
svnbook.org
Нет, читал лишь мануал.
mercurial мне понравился тем, что там минимум телодвижений: hg commit, hg push, hg pull, hg clone — вот и все, что я использую.
Я вот работаю в международной организации, представленной в более чем 100 странах мира. Они используют коммерческую систему MKS. Удивительно, правда? Вы, навернякак про такую ничего не слышали. Но соль в том, что там система контроля версий теснейшим образом интегрирована с системой управления заявками (Issues), так что процесса разработки поддержан от заведения заявки с куском функционала и до загрузки в систему установщика с обновлённой версией продукта, при этом можно закрыть заявку и уведомить всех заинтересованных. при этом настраиваются роли и права разных пользователей на каждое элементарное действие.

вот я знаю только один бесплатный аналог такого, это SVN и Redmine. а какую систему мжоно прикрутить к git, чтобы можно было контролировать связь задач с кусками?
Сегодня уже много кто умеет дружить с git (впрочем как и с svn): Redmine, Trac, MantisBT

По поводу MKS, автозакрытие тикетов — дело ерундовое. Даже если плагин к какой-то системе отсутствует, средний программист напишет крон-задачу за денек, делать вместо этого монолитную систему — это попахивает двойным not invented here :)
За ссылки спасибо, это интересно.
Я оценил больше не автозакрытие, а саму возможность заставить программеров каждый коммит привязывать к определённому тикету, и потом с этими change package работать, к примеру, делая cherry pick для переноса кода в другую ветку. При этом клиент один, написан на Жабе и умеет делать вообще всё, при этом интегрируется с проводником и студией. В общем, очень жду, когда появится такое сквозное решение, только бесплатное :-)
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.