Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 118
Предсказуемо, что svn…
Но уже меньше. -7% по сравнению с 2010 и -11% по сравнению с 2009 (на момент коментария).
Сам проголосовал за git, так как его использую для личных проектов и фриланса, в то время как svn только на работе.
Сам проголосовал за git, так как его использую для личных проектов и фриланса, в то время как svn только на работе.
Я правильно понимаю, что svn — это вселенское зло, которое надо искоренять так же как и windows во имя эры linux и git?
Ну не то чтобы зло. Но это представитель прошлого. Перед современными системами у него нет никаких преимуществ. Кроме (спорный вопрос) лучшего инструментария.
Ну так же и у Windows — перед современными системами у него нет никаких преимуществ кроме инструментария (софта под него).
Да брось, виндовс — хорошая система (для отдельных групп пользователей). Но я нахожу что если ты не связан с разработкой под виндовс (дотнет там и прочая), то ты получишь более комфортную жизнь в других системах.
Мой прошлый выбор — убунту. Текущий — макось. :-)
Мой прошлый выбор — убунту. Текущий — макось. :-)
cубъективно это. я пользуюсь и маком и убунтой и виндой. имхо win7 удобней в повседневной жизни
А что насчёт очень толстых проектов?
А что насчет них? Вот ядро линукса — это толстый проект или не очень? :-)
Думаю не очень. Вот какая-нибудь игра с кучей графики, звуков и прочих ресурсов — да. Не у каждого хватит места на харде, чтобы выполнить git clone.
Гит, как и прочие традиционные системы контроля версий, не приспособлен для хранения бинарных файлов. Для этого делают специальные системы.
Давно хотел узнать — а какие системы лучше использовать для управления именно бинарными файлами?
Ну вот например: www.nxn-software.com/
Есть, но не для программистов. Для нетехнического люда, да еще с не текстовыми документами (художники, к примеру) svn много проще для понимания (хотя бы последовательными номерами ревизий) и подразумевает администрирование репозитория специалистами.
Если Вы под инструментарием подразумеваете TortoiseSvn, то на сегодня TortoiseHg 2.х уже гораздо мощнее.
Я могу в git ограничить доступ к определенному каталогу внутри репозитория? Например разработчику на весь репозиторий дать ro, а на конкретный каталог rw?
Я могу в git сделать clone не всего репозитория а конкретного каталога внутри репозитория?
Для некоторый вещей в git надо делать костыли, когда в svn все гладко.
Я могу в git сделать clone не всего репозитория а конкретного каталога внутри репозитория?
Для некоторый вещей в git надо делать костыли, когда в svn все гладко.
пока живо зло в лице CVS, и так есть что искоренять
А смысл его искоренять, если svn вполне себе нормально работает и проще в использовании? Для проектов на несколько человек вполне подходит.
Вы хотели сказать привычней?
У нас SVN это страшный сон, git и mercurial наше все:)
А лично у меня незабываемые впечатления в свое время оставил SVN наличием или отсутствием слеша в конце пути репозитория. Как показывает просмотр открытых реп, не у меня одного :)
Сколько знаю людей, освоивших новые системы контроля, никто не хотел вернуться обратно на SVN.
У нас SVN это страшный сон, git и mercurial наше все:)
А лично у меня незабываемые впечатления в свое время оставил SVN наличием или отсутствием слеша в конце пути репозитория. Как показывает просмотр открытых реп, не у меня одного :)
Сколько знаю людей, освоивших новые системы контроля, никто не хотел вернуться обратно на SVN.
Думаю Git станет еще популярнее, когда доразовьются различные плагины для работы с ним в IDE. На мой взгляд подобный плагин для Netbeans пока еще убог.
Да, пожалуй, ты прав. Раньше я вообще не пользовался никакими гуёвинами. Через консоль было всё удобно. Пока не вышел гитхабовский клиент. Теперь пользуюсь поровну им и консолью.
Встроенными в IDEА средствами пока еще не было нужды пользоваться, даже мешают.
Встроенными в IDEА средствами пока еще не было нужды пользоваться, даже мешают.
Встроенными в IDEА средствами пока еще не было нужды пользоваться, даже мешают.
сомневаюсь, что в консоли можно реализовать такой же удобный диалог для сравнения и слияния конфликтующих изменений. Удобно просто из IDE быстро посмотреть что менял с последнего коммита, или сделать частичный коммит/роллбак. К тому же позволяет работать с разными VCS, если попался проект на неродная. В общем, я бы посоветовал посмотреть на встроенные средства, мне нравятся.
Проработал под Git-ом год, понял что у SVN есть свои отличные прелести
На основной работе svn, а для своих проектов используется Mercurial.
Пытаемся уже год как перейти на git или меркуриал, да всё руки не доходят, да и логи нужно все, диффы переносить как-то. В общем, пока что остаёмся на svn
Здесь сила привычки. Команда большая и всем нужно перенастраиваться итп. Дело не только не в диффах.
Расскажите о плюсах новой системы и пускай все на кошках попробуют
Первые пару недель плеваться будут, а потом — ничего, освоятся и будут предпочитать их SVNу)
Один каталог .git в корне рабочей копии лучше, чем множество .svn в каждом подкаталоге.
в svn 1.7 такой проблемы уже нет: subversion.apache.org/docs/release-notes/1.7.html#single-db
Мы думали о переезде с SVN на GIT порядка 3х месяцев, а потом раз и перешли. Да, по началу были проблемы, связанные с концепцией гита, но это быстро невелировалось плюсами гита. Мы вошли в нормальный ритм примерно за две недели.
Кстати как рекомендация советую подготовить mini-git-workflow, в который на первом этапе стоит добавить только важные моменты, которые пригодятся в 90% случаев, а остальное потом в процессе описать можно — очень помогает в работе. Такой список легко гуглится по запросу «howtogit».
Удачи :)!
Кстати как рекомендация советую подготовить mini-git-workflow, в который на первом этапе стоит добавить только важные моменты, которые пригодятся в 90% случаев, а остальное потом в процессе описать можно — очень помогает в работе. Такой список легко гуглится по запросу «howtogit».
Удачи :)!
Пока svn, но в планах перейти на какую-нибудь DVCS. Больше по душе конечно Bazaar :)
Вы уверены насчёт bzr? solovyov.net/blog/2011/01/24/bzr-hate-and-hate/
Уверен. Использую для своих домашних проектов. Есть даже ответ на данную статью groups.google.com/group/ru_bzr/msg/60f9fabcf6537199
Проголосовал за SVN.
Хотя на новых проектах переходим на Git
Хотя на новых проектах переходим на Git
Раньше использовал svn, но однажды познакомился с git и теперь на svn даже не смотрю.
Раньше использовал svn, потом познакомился с hg. Еще больше полюбил svn :)
Я бы ещё понял если Git, к нему привыкнуть сложнее. Но Mercurial… Вы что, серьёзно?
Серьезно :)
В то время как очень многие считают СВН деревянным, я считаю его просто легким и без излишков. А в hg (который от git-а принципиально ничем не отличается) слишком уж много всяких наворотов, бантиков и плюшечек.
В то время как очень многие считают СВН деревянным, я считаю его просто легким и без излишков. А в hg (который от git-а принципиально ничем не отличается) слишком уж много всяких наворотов, бантиков и плюшечек.
Это от людей зависит, у нас пол команды любит гит и считает, что в хг всё неправильно, другая половина говорит всё наоборот. Причём у всех есть свои хорошие доводы
Программисты с git работают.
Художники, дизайнеры с svn :)
Художники, дизайнеры с svn :)
Bazaar
осваивается за несколько минут, просто и удобно.
осваивается за несколько минут, просто и удобно.
Пользуюсь Git. Комиты в CVS/SVN/VSS
SVN и TFS
Я ввел и рассказал как работать с git на работе, теперь мы только им пользуемся, правда пришлост некоторое время бегать меж сотрудниками и помогать, но через полгода все привыкли.
Если бы не это, то по старинке бы пользовались svn.
Если бы не это, то по старинке бы пользовались svn.
Да-да, я так уже не один коллектив обратил :-)
а я начала обращать, а потом задумалась, а зачем, собственно, если и так неплохо… расскажите, какие у вас доводы? а то хочется гит, но как-то неубедительно для целой команды:)
Я на работе ввёл svn + Redmine (а до этого — svn + Trac).
А до этого по старинке долгие годы работали вообще без багтрекера и системы контроля версий.
Каких-то особых причин переводить людей на git не вижу — у нас и svn-то кроме программистов никто не использует — разве что дизайнеры, которые рядом и которых можно легко агитировать за.
А до этого по старинке долгие годы работали вообще без багтрекера и системы контроля версий.
Каких-то особых причин переводить людей на git не вижу — у нас и svn-то кроме программистов никто не использует — разве что дизайнеры, которые рядом и которых можно легко агитировать за.
В чем я точно уверен, так что для дизайнеров git — зло.
Для программистов же (субъективно) лучше git или hg, потому что позволяют много чего коммитить, перекоммичивать, откоммичивать обратно перед тем как отсылать в центральный репо. Ветки в svn это действительно жутко неудобно (svn switch долгий, svn merge глупый, svn commit публичный), понимаешь это когда начинаешь работать с гитом. Также за простой git init && git commit -a -m «Start» в любой неверсионнированной папке в которой я хочу что-то поменять я продам родину :)
Для программистов же (субъективно) лучше git или hg, потому что позволяют много чего коммитить, перекоммичивать, откоммичивать обратно перед тем как отсылать в центральный репо. Ветки в svn это действительно жутко неудобно (svn switch долгий, svn merge глупый, svn commit публичный), понимаешь это когда начинаешь работать с гитом. Также за простой git init && git commit -a -m «Start» в любой неверсионнированной папке в которой я хочу что-то поменять я продам родину :)
svn все реже — Mercurial все чаще
Основной проект на SVN. Новое делаю на Git. Возможно, к концу года окончательно на git перееду.
Почему в опросе не чекбоксы? Мы используем и git и Mercurial.
git используем, бранчи и стэш это сила.
Вижу, что нет никого, кто использовал бы Стартим.
И правильно делаете, что не используете! Я вот с ним намучился в своё время…
Сейчас svn.
И правильно делаете, что не используете! Я вот с ним намучился в своё время…
Сейчас svn.
Проголосил за git, хотя несколько проектов до сих пор болтается в Mercurial, ну а с svn ушел уже года 3 как.
Mercurial, но исключительно потому, что на нём работает Bitbucket, а им я пользуюсь, потому что там можно бесплатно создавать закрытые репозитории.
Да, теперь там уже есть поддержка и GIT, но на моей машине GIT настроен для GitHub, а удобного способа жонглировать несколькими аккаунтами я не знаю.
Да, теперь там уже есть поддержка и GIT, но на моей машине GIT настроен для GitHub, а удобного способа жонглировать несколькими аккаунтами я не знаю.
Используем SVN, но помимо нее сделал себе скрипты инкрементального копирования через rdiff-backup.
Резервное инкрементальное копирование запускаю перед Commit/Update, чтобы обезопасить себя от вредителей, которые пишут код не в рабочей директории, находящейся под контролем SVN, а в боковой. Эти товарищи держат директорию, в которой работают, где-то в другом месте, а когда нужно синхронизироваться, копируют файлы в рабочую директорию SVN, а потом забирают их.
Проблема в том, что перед синхронизацией им надо вначале запускать синхронизацию рабочей директории, забирать файлы из рабочей директории себе, параллельно посмотрев, изменили ли они сами там что нибудь. Проверить работоспособность, залить в рабочую директорию, засинхронизироваться. Но кто бы это делал! Копируют файлы просто из своей «боковой» директории в рабочую, и синхронизируются.
В результате, новые изменения, которые уже есть на сервере, и залиты до этих деятелей, возвращаются к предыдущему состоянию так как переписываются поверх из устаревших файлов, которые деятели копировали из боковой директории в рабочую (у них же новых изменений нет).
Дело усугубляется тем, что могут скопировать в рабочую директорию каталог с подкаталогом .svn, и тогда начинается максимально жосткая чехорда с изменениями, которые были приняты/потеряны/переписаны более поздней версией.
Вот тут-то приходится расчехлять архив rdiff-backup и смотреть как оно должно быть на предыдущем этапе, когда программа работала хотя бы у меня.
Резервное инкрементальное копирование запускаю перед Commit/Update, чтобы обезопасить себя от вредителей, которые пишут код не в рабочей директории, находящейся под контролем SVN, а в боковой. Эти товарищи держат директорию, в которой работают, где-то в другом месте, а когда нужно синхронизироваться, копируют файлы в рабочую директорию SVN, а потом забирают их.
Проблема в том, что перед синхронизацией им надо вначале запускать синхронизацию рабочей директории, забирать файлы из рабочей директории себе, параллельно посмотрев, изменили ли они сами там что нибудь. Проверить работоспособность, залить в рабочую директорию, засинхронизироваться. Но кто бы это делал! Копируют файлы просто из своей «боковой» директории в рабочую, и синхронизируются.
В результате, новые изменения, которые уже есть на сервере, и залиты до этих деятелей, возвращаются к предыдущему состоянию так как переписываются поверх из устаревших файлов, которые деятели копировали из боковой директории в рабочую (у них же новых изменений нет).
Дело усугубляется тем, что могут скопировать в рабочую директорию каталог с подкаталогом .svn, и тогда начинается максимально жосткая чехорда с изменениями, которые были приняты/потеряны/переписаны более поздней версией.
Вот тут-то приходится расчехлять архив rdiff-backup и смотреть как оно должно быть на предыдущем этапе, когда программа работала хотя бы у меня.
А зачем они держат файлы в соседней папке?
Насколько я помню, то (лет пять назад) SVN уже не давал делать коммит, если в репе есть ревизия новее. То есть, затереть свежие изменения можно было лишь обновив локальную копию, а потом скопировать поверх неё файлы из соседней папки.
Если дата файла поменялась, то закоммитится.
> То есть, затереть свежие изменения можно было лишь обновив локальную копию, а потом скопировать поверх неё файлы из соседней папки.
И это тоже делали. На вопрос зачем — «я забыл после обновления скопировать в свою папку изменения».
> То есть, затереть свежие изменения можно было лишь обновив локальную копию, а потом скопировать поверх неё файлы из соседней папки.
И это тоже делали. На вопрос зачем — «я забыл после обновления скопировать в свою папку изменения».
Svn на работе. Свои проекты в hg.
Жутко неудобное и тормозное «Хранилище» 1С. Потому как других вариантов нет.
Другая бесплатная распределенная VCS: fossil-scm.org/ (+трекер, +wiki на встроенном сервере) — размер 1Мб — от создателя SQLite.
Я честно пытался понять философию git, но «не судьба». Пытался и на придуманных проектах познать его мощь, и на корпоративных больших и сложных. Запутался, не увидел никаких преимуществ для себя и команды перед svn-ом.
С удовольствием бы прочёл дельную статью о git: преимущества, основы (по новому кругу), как правильно использовать, в чём фишка распределённого контроля. Может когда-то дорастём до git, но пока выбрал svn.
С удовольствием бы прочёл дельную статью о git: преимущества, основы (по новому кругу), как правильно использовать, в чём фишка распределённого контроля. Может когда-то дорастём до git, но пока выбрал svn.
А ты смотрел то знаменитое выступлени Линуса? Меня именно оно убедило.
Фишка в полном репозитории у каждого, регулярных коммитах без паски сломать транк и постоянных ветвлениях
Сейчас не 2005 год, все это легко гуглится заинтересованным человеком. Вставать в позицию «удивите меня» как-то неконструктивно.
У меня уникальная ситуация — я использую на работе CVS, TFS 2010 и Mercurial. Первые две люто ненавижу, Mercurial наиболее удобен.
TFS уже года полтора. В целом, если к нему привыкнуть — довольно удобен.
Mercurial, начал работать с VCS совсем недавно. Сначала пробовал git — не разобрался, потом попробовал SVN — тоже ничего не понял.
А hg достаточно прост.
А hg достаточно прост.
«Version Control with Subversion» читали?
Она же — «Управление версиями в Subversion» (перевод частичный, в основном переведены начальные главы, где введение и инструкции для пользователей).
Написано достаточно понятно.
svnbook.org
Она же — «Управление версиями в Subversion» (перевод частичный, в основном переведены начальные главы, где введение и инструкции для пользователей).
Написано достаточно понятно.
svnbook.org
Я вот работаю в международной организации, представленной в более чем 100 странах мира. Они используют коммерческую систему MKS. Удивительно, правда? Вы, навернякак про такую ничего не слышали. Но соль в том, что там система контроля версий теснейшим образом интегрирована с системой управления заявками (Issues), так что процесса разработки поддержан от заведения заявки с куском функционала и до загрузки в систему установщика с обновлённой версией продукта, при этом можно закрыть заявку и уведомить всех заинтересованных. при этом настраиваются роли и права разных пользователей на каждое элементарное действие.
вот я знаю только один бесплатный аналог такого, это SVN и Redmine. а какую систему мжоно прикрутить к git, чтобы можно было контролировать связь задач с кусками?
вот я знаю только один бесплатный аналог такого, это SVN и Redmine. а какую систему мжоно прикрутить к git, чтобы можно было контролировать связь задач с кусками?
Сегодня уже много кто умеет дружить с git (впрочем как и с svn): Redmine, Trac, MantisBT…
По поводу MKS, автозакрытие тикетов — дело ерундовое. Даже если плагин к какой-то системе отсутствует, средний программист напишет крон-задачу за денек, делать вместо этого монолитную систему — это попахивает двойным not invented here :)
По поводу MKS, автозакрытие тикетов — дело ерундовое. Даже если плагин к какой-то системе отсутствует, средний программист напишет крон-задачу за денек, делать вместо этого монолитную систему — это попахивает двойным not invented here :)
За ссылки спасибо, это интересно.
Я оценил больше не автозакрытие, а саму возможность заставить программеров каждый коммит привязывать к определённому тикету, и потом с этими change package работать, к примеру, делая cherry pick для переноса кода в другую ветку. При этом клиент один, написан на Жабе и умеет делать вообще всё, при этом интегрируется с проводником и студией. В общем, очень жду, когда появится такое сквозное решение, только бесплатное :-)
Я оценил больше не автозакрытие, а саму возможность заставить программеров каждый коммит привязывать к определённому тикету, и потом с этими change package работать, к примеру, делая cherry pick для переноса кода в другую ветку. При этом клиент один, написан на Жабе и умеет делать вообще всё, при этом интегрируется с проводником и студией. В общем, очень жду, когда появится такое сквозное решение, только бесплатное :-)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Какую систему управления версиями вы используете? (в реальной работе, больше всего)