Системы управления версиями *

Скоро выходит Team Foundation Server 11. Это новый крупный выпуск, который включает в себя много нового как для разработчиков, так и для менеджеров проектов, тестировщиков и аналитиков.
В Team Foundation Server 11, вводится новая версия, которая называется Team Foundation Server Express.

В этой публикации будет рассказано именно о бесплатной редакции Express. Публикация предназначена для начинающих разработчиков и тех, кто еще не работал с Team Foundation Server.

Преамбула:
Имеем в наличии TortoiseSVN и Total Commander, и активно их используем в работе.
Практически все действия в Total Commander'e успешно совершаются одной только клавиатурой, без использования мышки, какими-либо горячими клавишами. Главное их найти/знать/привыкнуть, и работа становится в разы проще и быстрее.
TortoiseSVN же из коробки предоставляет нам только пункты в контекстном меню, до которого можно добраться двумя способами:

• Мышкой. При активной работе, тянуться каждый раз до мышки, реально начинает напрягать уже через пару дней/часов/минут работы (зависит от крепости нервов разработчика) и времени занимает это довольно много.
• Через клавишу контекстного меню + стрелок. Этот вариант конечно чем-то проще и быстрее (ибо не надо тянуться за мышкой), но всё так же не удобен и всё такой же медленный.

Хочется все действия с TortoiseSVN выполнять так же быстро, как и действия в самом Total Commander'e.
Т.е. через горячие клавиши, в одно нажатие.

Облазив просторы интернета, не смог найти ни одной инструкции, как можно по-человечески интегрировать TortoiseSVN в Total Commander и сделать это возможным.
Поэтому решил написать свой небольшой простенький мануал.

При клонировании репозитория с помощью команды

hg clone A B

mercurial сначала пытается создать жесткие ссылки для файлов внутри папки .hg в новом репозитории. Это ускоряет клонирование и экономит место на жестком диске.

Жесткие ссылки поддерживаются файловыми системами Linux и Windows NTFS. Для файловых систем, которые не поддерживают жесткие ссылки (например Windows FAT), а также при клонирование через http/https или ssh с удаленного сервера mercurial полностью копирует все файлы.

Добрый день, коллеги.

Длинные праздники заканчиваются, и уже завтра, мы снова погрузимся в пучину ежедневной рутины. Сегодня, на стыке еще не закончившихся праздников и еще не начавшейся рабочей недели, я бы хотел немного рассказать о непрерывной интеграции.
Начиная внедрять Agile практики в разработке, многие, прочитав: «Личности и их взаимодействия важнее, чем процессы и инструменты», приходят в восторг. Ведь можно собрать команду, сплотить их, поставить задачи и вот она: «звезда пленительного счастья» (работающее и полезное пользователям ПО). Но, к сожалению, в жизни бывает все намного скучнее и непредсказуемей. Начиная внедрять новомодный Scrum или Kanban, часто забывают, что все достоинства этих методик проявляться только в том случае, если они ложатся на правильные инженерные практики. К таким практикам относят модульное тестирование вообще, и TDD в частности; парное программирование; Code Review; непрерывную интеграцию и многое другое.
Под катом, я попробую показать, как настроить непрерывную интеграцию в рамках TFS 11 и в каких сценариях, какой способ построения проектов будет наиболее оправдан (много картинок и текста).

Вот и мне посчастливилось познакомиться с git. Каюсь, пользуясь Subversion, я знал, как в IDEA или TortoiseSVN сделать то, что мне надо, но даже не представлял, что происходит за сценой. В данном случае я решил подойти к git более ответственно и хорошенько изучить его перед использованием. Сейчас я знаю какие команды надо использовать для выполнения задуманного, но не знаю, как это сделать в IDEA или TortoiseSVN.
Но я решил пойти еще дальше и узнать, что происходит в самой директории .git. Там оказалось все настолько интересно и просто, что я решил поделиться этим с вами.

От переводчика: в этой статье нет описания команд git, она подразумевает, что вы уже знакомы с ним. Здесь описывается вполне здравый, на мой взгляд, подход к содержанию публичной истории в чистоте и порядке.

Если вы не понимаете, что побудило сделать git именно таким, то вас ждут страдания. Используя множество флагов (--flag), вы сможете заставить git работать так, как по вашему мнению он должен работать, вместо того, чтобы работать так, как git того хочет. Это как забивать гвозди отверткой. Работа делается, но хуже, медленнее, да и отвертка портится.

Гуляя по github'у я много раз видел в разных репозиториях одновременно и теги вида «v2.3.4» и коммиты с сообщениями типа «Bump version» и сменой номеров версии где-нибудь в lib/version.rb. И всегда мне казалось — что-то тут лишнее.

И когда пришло время задуматься и мне над расставлением номеров версий, я сказал: «Нет! Я не буду прописывать эти номера в файлы руками. Пусть это делает за меня моя система контроля версий!»

Как ни странно, но среди программистов ещё довольно много тех, кто не видит смысла в системах контроля версий (СКВ) или попросту не знает о них. Хватает и тех, кто знает, но не в курсе с чего начать внедрение или, при использовании, проходят мимо очень удобных возможностей.

Доброго времени суток!

Данная статья посвящена одной небольшой задачке – переносу репозитория вместе со всей историей с одной системы управления версиями в другую, а точнее – в SVN. Речь пойдёт об использовании бесплатной утилиты Importer for SVN от Palarion, с помощью которой можно мигрировать с CVS / PCVS / VSS / ClearCase / StarTeam / MKS на SVN, не потеряв при этом журнала изменений кода. В моём случае потребовалось перенести проекты из Borland StarTeam.

Почему было сказано «нет» StarTeam и «да» SVN? Сначала думал пропустить данный абзац во избежание холиваров. Но, пожалуй, без этого статья была бы лишена, скажем так, области определения. В моём случае отказаться от StarTeam вынудил уход человека, его внедрившего и администрировавшего. Пара дней безуспешных попыток заставить работать сервис под другой учётной записью породили мысль о том, что задача восстановления репозиториев из бэкапов станет ещё большим вызовом. Конечно, радиус кривизны рук можно было значительно увеличить спустя какое-то время. Но оно нам надо, спрашивается, когда есть бесплатный, до безобразия лёгкий в установке и поддержке SVN? Тем более что у меня было предостаточно опыта его использования на предыдущих местах работы, а все два с половиной разработчика находятся в одной комнате.

Одно препятствие – жаль было терять историю изменений. Сначала думали залить в SVN текущие версии, а историю смотреть в StarTeam, переведя его предварительно в read-only. Но, как говорится, это не наш метод. И непродолжительный гуглопоиск навёл на выше в суе помянутый Palarion Importer for SVN.

Чтобы управлять доступом можно использовать различные решения gitosys, gitolite, mercurial-server, но эти решения работают через SSH, что не всегда удобно (должен быть ключ). В добавок не хватает гибкости у подобных решений.

Основные требования:

• доступ по логину/паролю (HTTPS)
• контроль прав на чтение/запись
• публичный/приватный репозиторий
• управления всем через веб интерфейс
• все данные (информация о проекте и пользователях) должны храниться в базе (MySQL)

Для решения этой задачи сделал следующую систему…

Способов хостинга mercurial репозиториев достаточно, но я сочинил именно такой вариант по следующим причинам:

1. nginx: мало кушает, быстро работает — скорость
2. supervisor: мониторит процесс, перезапускает если что — надёжность
3. gunicorn: wsgi, большие возможности по настройке — эффективность

Кроме того, т.к. я разрабатываю на django, и сайты запускаю под этой же связкой, есть и четвёртая причина — унификация, а она очень полезная вещь.

Если вас заинтересовала тема, то конкретные инструкции и конфиги — под катом.

Данный зверь будет полезен тем, кто не пользуется GUI утилитами при работе с git, mercurial и т.д., а чувствует себя комфортно работая с ними из консоли.
vcprompt.com — python скрипт, который будет выводить основную информацию по версии VCS в текущей директории, если такова есть. Как то название VCS, текущую ветку, были ли изменения с последнего коммита и ещё несколько параметров, которые можно задать в формате вывода.

Статистика Debian позволяет вполне объективно сравнить популярность различных систем управления версиями. Git на графике обозначен зелёным цветом.


^{Количество инсталляций систем управления версиями за 2004-2011 гг}

Статистика собирается с пользователей, которые установили пакет popularity-contest (popcon). После установки popcon еженедельно отсылает в Debian по электронной почте информацию об установленных в системе пакетах и времени последнего использования.

Cruise Control — одна из достаточно большого количества CI (continuous integration) систем. Речь пойдет о том, как настроить ее для связи с SVN и деплоя сайта на .NET.

Для начала немного о задачах СС на данном сервере:

• Взять код из SVN репозитория
• Скомпилировать его
• Положить в директорию к IIS

Далее будут выложены куски конфигурационного файла, с комментариями по каждой хоть как-то интересной строчке. По кускам, фактически выложен полный рабочий конфиг.

 

Apache Software Foundation объявила о выпуске Subversion 1.7, но какие именно из новых возможностей 1.7 полезны пользователю? А почему бы вам не обновиться до версии 1.7? Под катом пять причин перехода на Subversion 1.7.

После двух с половиной лет разработки свет увидел новый major релиз централизованной системы управления версиями subversion: что нового, видео обзор.

• Скачать TortoiseSVN для Windows (GUI,CMD) или SlikSVN (только CMD)
• Скачать для OSX
• Для *NIX можем собрать из исходников сами.

На сервисе для хостинга проектов и их совместной разработки BitBucket произошли значительные изменения.

Работая с svn нередко появляются моменты, когда во время коммита твой рабочий каталог становится неактуальным. При этом приходится обновлять свою локальную копию из репозитория и составлять коммит по-новой. Хорошо когда коммитить нужно всё, а если нужны лишь три файла из ста? В таком случае приходится по новой искать свои файлы. Хотя TortoiseSVN и упрощает жизнь в таких случаях, бережно сохраняя комментарий, но всё равно, время, потраченное на обновление каталога и получение дерева с удаленного SVN сервера не вернуть. Создатели TortoiseSVN упростили нам жизнь ещё больше, создав небольшую утилиту, речь о которой и пойдет в данной статье – CommitMonitor.

Некоторое время назад я опубликовал очень многословное сочинение, где пытался объяснить, почему Git серьёзно поломан, и почему всем следует вместо этого пользоваться Mercurial, до тех пор, пока разработчки Git его не починят. Ну ладно, я был не настолько груб, но близок к этому.

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

Ниже я нарисовал упрощёный граф истории репозитория Git с тремя созданными ветками: «master», «release» и «topic». До того, как энтузиасты Git начнут ругаться, что я исхитрился показать нереально плохой случай запутанности истории, позвольте мне заверить вас, что это на самом деле ещё упрощённый пример. У меня есть доступ к реальному репозиторию Git, где создано шесть рабочих веток релизов, около сорока рабочих тематических веток и несколько сотен ранее существовавших веток, которые уже удалены с центрального сервера.