Системы управления версиями → Популярность систем управления версиями среди пользователей Debian
Статистика Debian позволяет вполне объективно сравнить популярность различных систем управления версиями. Git на графике обозначен зелёным цветом.
Количество инсталляций систем управления версиями за 2004-2011 гг
Статистика собирается с пользователей, которые установили пакет popularity-contest (popcon). После установки popcon еженедельно отсылает в Debian по электронной почте информацию об установленных в системе пакетах и времени последнего использования.
Количество инсталляций систем управления версиями за 2004-2011 гг
Статистика собирается с пользователей, которые установили пакет popularity-contest (popcon). После установки popcon еженедельно отсылает в Debian по электронной почте информацию об установленных в системе пакетах и времени последнего использования.
Системы управления версиями → Какую систему управления версиями вы используете? (в реальной работе, больше всего)
Git → GitHub совершенствует поддержку svn
Около полутора лет назад мы анонсировали поддержку svn, которая позволила ограниченно использовать репозитории GitHub через клиенты subversion.
Сегодня мы запускаем новую улучшенную поддержку svn.
Сегодня мы запускаем новую улучшенную поддержку svn.
Что нового?
Системы управления версиями → Контролируем коммиты в SVN под Windows
Работая с svn нередко появляются моменты, когда во время коммита твой рабочий каталог становится неактуальным. При этом приходится обновлять свою локальную копию из репозитория и составлять коммит по-новой. Хорошо когда коммитить нужно всё, а если нужны лишь три файла из ста? В таком случае приходится по новой искать свои файлы. Хотя TortoiseSVN и упрощает жизнь в таких случаях, бережно сохраняя комментарий, но всё равно, время, потраченное на обновление каталога и получение дерева с удаленного SVN сервера не вернуть. Создатели TortoiseSVN упростили нам жизнь ещё больше, создав небольшую утилиту, речь о которой и пойдет в данной статье – CommitMonitor.
Сетевые технологии → Сбор конфигурации сетевого оборудования и хранение их в SVN из песочницы
Не так давно, в связи с расширением штата сетевых администраторов, роста числа оборудования в сети и круга задач, возлагаемых на это оборудование, возникло желание отслеживать изменение его конфигурации, и хранить историю этих изменений.
Очевидным решением стало хранение конфигурации в системе управления версиями. Выбор пал на Subversion, так же известную как SVN.
На установке и настройке репозитория останавливаться не буду, так как этому посвящено много страниц в интернете и ничего нестандартного в этом нету. Здесь опишу свой способ сбора конфигурации с оборудования и учет изменений.
Очевидным решением стало хранение конфигурации в системе управления версиями. Выбор пал на Subversion, так же известную как SVN.
На установке и настройке репозитория останавливаться не буду, так как этому посвящено много страниц в интернете и ничего нестандартного в этом нету. Здесь опишу свой способ сбора конфигурации с оборудования и учет изменений.
Веб-разработка → Ветки в SVN
Особенностью современной веб разработки является полное отсутствие планирования при создании, поддержке и выкатке проектов. Это приводит к ситуации, что достаточно часто параллельно выполняется несколько разных задач и сроки их выкатки в production никак не соотносятся. А значит традиционный подход с созданием релизов не годится.
На помощь нам приходит механизм создания веток в системах контроля версий, VCS (в нашем случае это Subversion). Ветки это разные варианты одного документа или проекта, с общей историей изменений до точки ветвления и с разными — после неё.
На помощь нам приходит механизм создания веток в системах контроля версий, VCS (в нашем случае это Subversion). Ветки это разные варианты одного документа или проекта, с общей историей изменений до точки ветвления и с разными — после неё.
Проектирование и рефакторинг → Рефакторинг проекта в SVN с помощью ANT из песочницы
В статье описывается способ разделения логики и реализации логики в ant-скриптах, примененный для решения одной практической задаче по рефакторингу большого проекта в SVN-репозитории.
Имеется проект в SVN из 15 000 файлов и 5 000 папок. Проекту почти 10 лет, на нем поработало несколько поколений разработчиков разной квалификации. В какой-то момент, пару-тройку лет назад, а может и раньше, архитектура проекта «потекла». Разные модули и слои стали писаться в разных стандартах организации кода, возникли циклические зависимости между модулями. В итоге в SVN за долгие года образовалась свалка. Проект собирается, но совершенно шаманским способом.
Привести код к единому формату хранения. При этом сохранить историю изменений по каждому файлу и не останавливать процесс разработки.
Сохранить историю по одному файлу или папке в SVN довольно просто с помощью команды svn copy. При небольшом количестве файлов все можно сделать вручную.
С разбором большого проекта сложно. Пока будешь вручную разбирать 15 000 файлов, разработчики накоммитят новых изменений и их тоже нужно будет копировать. Замкнутый круг.
Нужна автоматизация. Скриптик, который раз! — и переводит проект в новую структуру.
Задача была выполнена, а побочным продуктом стал подход к написанию ANT-скриптов, который в большом программировании называется инкапсуляция. Хочу поделиться полученным подходом.
Предыстория
Имеется проект в SVN из 15 000 файлов и 5 000 папок. Проекту почти 10 лет, на нем поработало несколько поколений разработчиков разной квалификации. В какой-то момент, пару-тройку лет назад, а может и раньше, архитектура проекта «потекла». Разные модули и слои стали писаться в разных стандартах организации кода, возникли циклические зависимости между модулями. В итоге в SVN за долгие года образовалась свалка. Проект собирается, но совершенно шаманским способом.
Задача
Привести код к единому формату хранения. При этом сохранить историю изменений по каждому файлу и не останавливать процесс разработки.
Сложности
Сохранить историю по одному файлу или папке в SVN довольно просто с помощью команды svn copy. При небольшом количестве файлов все можно сделать вручную.
С разбором большого проекта сложно. Пока будешь вручную разбирать 15 000 файлов, разработчики накоммитят новых изменений и их тоже нужно будет копировать. Замкнутый круг.
Нужна автоматизация. Скриптик, который раз! — и переводит проект в новую структуру.
Результат
Задача была выполнена, а побочным продуктом стал подход к написанию ANT-скриптов, который в большом программировании называется инкапсуляция. Хочу поделиться полученным подходом.
Perl → Perl::Critic + Subversion = внедрение единых практик кодирования в команде из песочницы
Язык Perl хорошо известен той степенью свободы (a.k.a. TIMTOWTDI), которую он даёт программисту в выборе способа решения той или иной задачи. У этой медали, к сожалению, есть и оборотная сторона, которая может проявиться при командной разработке крупных проектов. Если в команде нет единых практик кодирования и каждый из разработчиков придерживается принципа TIMTOWTDI, то новичку в таком коллективе не позавидуешь.
В 2005 году активный участник Perl-сообщества Дамиан Конвей (Damian Conway) опубликовал книгу Perl Best Practices, в которой собрал и структурировал 256 рекомендаций по написанию понятного, надёжного и поддерживаемого Perl-кода. Краткую шпаргалку с выжимкой из книги можно скачать отсюда.
Годом позже, Jeffrey Thalhammer и группа товарищей выпустила Perl::Critic — гибкий и расширяемый фреймворк, позволяющий автоматизировать проверку Perl-кода на предмет его соответствия большей части рекомендаций из книги Конвея, а также многих других полезных практик.
Perl::Critic подаётся под разными соусами: во-первых, в комплекте с модулем поставляется одноимённая утилита — perlcritic, во-вторых, проверку кода можно оформить в виде тестов с помощью Test::Perl::Critic либо Test::Perl::Critic::Progressive, в-третьих, критик легко интегрируется в VIM и Emacs.
В этом рецепте я расскажу о том как проверять Perl-код на лету при коммите в Subversion-репозиторий. Bon Appétit!
В 2005 году активный участник Perl-сообщества Дамиан Конвей (Damian Conway) опубликовал книгу Perl Best Practices, в которой собрал и структурировал 256 рекомендаций по написанию понятного, надёжного и поддерживаемого Perl-кода. Краткую шпаргалку с выжимкой из книги можно скачать отсюда.
Годом позже, Jeffrey Thalhammer и группа товарищей выпустила Perl::Critic — гибкий и расширяемый фреймворк, позволяющий автоматизировать проверку Perl-кода на предмет его соответствия большей части рекомендаций из книги Конвея, а также многих других полезных практик.
Perl::Critic подаётся под разными соусами: во-первых, в комплекте с модулем поставляется одноимённая утилита — perlcritic, во-вторых, проверку кода можно оформить в виде тестов с помощью Test::Perl::Critic либо Test::Perl::Critic::Progressive, в-третьих, критик легко интегрируется в VIM и Emacs.
В этом рецепте я расскажу о том как проверять Perl-код на лету при коммите в Subversion-репозиторий. Bon Appétit!
Блог компании Microsoft → Как мигрировать с SVN на TFS
Многие команды, которые используют Subversion для хранения исходных кодов к некоторому моменту начинают задумываться о построении полноценной среды управления жизненным циклом разработки (Application Lifecycle Management). При этом возникают непростые вопросы. В первую очередь это то, как объединить средства контроля версий, управления задачами, багами, артефактами и сборками проекта в единую систему. Путей тут два – либо развивать текущий комплекс, постепенно подключая к нему недостающие компоненты, либо мигрировать на систему, которая все эти компоненты содержит. Для тех команд, которые используют в качестве основного инструмента Visual Studio, подходящим вариантом является Team Foundation Server. Но при этом возникает несколько важных вопросов – как минимизировать время простоя команды, а еще лучше сделать процесс миграции незаметным.
Системы управления версиями → История одного Репозитория
Эта история началась много-много ревизий назад – тогда SVN Репозиторий был девственно чист, и ни один баг еще не осквернил его своим присутствием. Первые коммиты, первые откаты, просмотры лога – все это было так захватывающе, так ново. И разве мог Репозиторий тогда предполагать, что эти первые, такие приятные шаги впоследствии приведут его на хирургический стол?
Репозиторий рос, креп, матерел. Со временем привык к коммитам, появились первые тэги, и даже мечты о ветках перестали казаться несбыточными. Репозиторий познакомился с другими SVN репозиториями, а с некоторыми даже стал обмениваться файлами. Порой он подолгу выкачивал изменения у своих новых друзей, по ходу процесса наслаждаясь анализом диффов.
Репозиторий рос, креп, матерел. Со временем привык к коммитам, появились первые тэги, и даже мечты о ветках перестали казаться несбыточными. Репозиторий познакомился с другими SVN репозиториями, а с некоторыми даже стал обмениваться файлами. Порой он подолгу выкачивал изменения у своих новых друзей, по ходу процесса наслаждаясь анализом диффов.