Интервью с chemodax

Иван Жаков, технический директор VisualSVN, Apache Subversion Committer


За что вам дали Visual Studio Magazine Readers Merit Award?
По моему мнению, это результат долгосрочных инвестиций в качество нашего продукта. Под качеством я подразумеваю отсутствие багов, продуманный интерфейс и адекватную производительность. Пользователь ставит себе VisualSVN for Visual Studio и начинает им пользоваться в ежедневном режиме. Через некоторое время пользователь понимает: вау, мне действительно нравится этот продукт. Другими словами, VisualSVN — это невидимый продукт, который просто делает свое дело, при этом не претендуя на звание «самого главного плагина».


Можешь привести пример фичи VisualSVN, которая особенно нравится вашим пользователям?
Когда пользователь редактирует файлы, VisualSVN сразу подсвечивает все измененные строчки. Между изменения можно легко перемещаться. Это очень важно, потому что развивает инкрементальное отношение к коду. С какого-то момента история изменений исходного кода становится не менее важной, чем текущее состояние этого кода. Мы акцентируем внимание программиста на изменениях и даем возможность мгновенно их посмотреть.

Есть ли у вас конкуренты?
Конкурентов у нас достаточно. Кто-то практически полностью копирует наши продукты, у кого-то свой рынок. В целом у нас тут совсем не санаторий.

Планируете ли вы делать аналогичные продукты для других IDE?
Наличия функций API для загрузки плагинов в IDE не достаточно для разработки плагинов, особенно коммерческих. Это API должно быть стабильным, должны быть гарантии обратной совместимости. Более того, должна быть уверенность, что производитель IDE не передумает, не решит сам реализовать то же самое, не обанкротится, в конце концов. Да и вообще, мы стараемся делать меньше, но лучше. На данный момент наш фокус — Subversion for Windows. В частности, Subversion for Visual Studio.

Можешь рассказать о работе с Microsoft?
Microsoft, несмотря на свою репутацию, очень хорошо относится к своим партнерам. Мне доводилось с этим сталкиваться в двух качествах: и как разработчику VisualSVN, и как члену Apache Software Foundation. Например, перед выпуском Windows Server 2008 разработчиков Apache Software Foundation пригласили в Redmond (за счет Microsoft), чтобы убедиться, что у продуктов, которые выпускает ASF, не будет проблем с новой ОС. И это при том, что Apache HTTP Server является прямым конкурентом Microsoft IIS. До этого Microsoft так же приглашал разработчиков Mozilla Firefox, чтобы у Firefox не было проблем под Windows Vista.

Примерно такое же отношение и к разработчикам плагинов для Visual Studio. Несколько раз в год для разработчиков плагинов проходит developers clinic. Это даёт нам возможность пообщаться с разработчиками Visual Studio, прямо в отладчике решить какие-то проблемы, если они есть.


Как так получилось, что ты занялся системами контроля версий?
Я работал в одной достаточно известной питерской компании, исторически там использовался Visual SourceSafe. За долгие годы в компании предпринималось несколько попыток перейти на другую систему управления версиями. Но все эти попытки, к сожалению, закончились неудачей. Причиной неудач были не технические сложности, а сопротивление разработчиков. Так получилось, что в какой-то момент наш отдел перешел на Subversion. Я взял небольшой perl-вский скрипт, сконвертировал нашу базу из SourceSafe в Subversion, а системный отдел сделал для нас сервер.

Видимо этот опыт показался руководству успешным и меня пригласили перейти в системный отдел, чтобы я занялся переводом на Subversion остальных отделов. Какое-то время я потратил на правильную настройку сервера, организацию бэкапа, разработку процедур для системных администраторов для разных ситуаций, доработку скрипта для конвертации из SourceSafe в Subversion. Это была длительная, но относительно простая фаза проекта. Самым сложной частью проекта оказалось убеждение людей. Я ходил по отделам и рассказывал ведущим разработчикам про преимущества Subversion. Объяснял им, как Subversion может удовлетворить их потребности и почему он сделает это лучше чем SourceSafe. И так получилось, что в одном из отделов мне указали на реальный баг в Subversion. На тот момент я искренне удивился, что в нём есть такие серьезные ошибки! Я начал посылать патчи, чтобы исправить эту ошибку. Через некоторое время мне дали commit access и я стал Subversion Full Committer.

Забавно, что через несколько лет упомянутая питерская компания независимо от меня перешла на использование VisualSVN Server! Наверное, потому что VisualSVN Server делает все настройки, на которые я потратил полгода, прямо из коробки.

VisualSVN Server — это популярный продукт?
Я сам удивляюсь насколько. Иногда мне кажется, что VisualSVN Server стоит в каждой кофеварке. Например, мы недавно подсчитали, что сервер был скачан более 800 тысяч раз. Это конечно не Angry Birds, но для серверного продукта это очень много.

А кто пользуется VisualSVN Server?
На удивление, пользователи VisualSVN Server очень разные: от банков, нефтяных компаний и правительственных организаций до студентов которые ставят VisualSVN Server на свой домашний компьютер, чтобы совместно со своим однокурсником разрабатывать дипломный проект. VisualSVN Server сейчас используется для хранения очень разной информации: от исходных текстов до конфиденциальных документов.

Не планируете ли вы продавать VisualSVN Server как сервис?
VisualSVN Server удобнее хостингового решения — во внутренней сети он будет ближе к пользователям и интеграция с Active Directory позволит работать с Subversion без ввода пароля. Хостинг — это скорее администрирование, а это не наша специализация. Мы занимаемся разработкой программного обеспечения.

А почему ты решил заняться Subversion, а не какой-нибудь другой системой контроля версий?
Текущий девиз Subversion звучит так: Enterprise-class centralized version control for the masses. И этот девиз соответствует состоянию продукта и планам по его развитию. Subversion — это очень качественный продукт, который идеально подходит большинству компаний. Исходный код всех проектов Apache Software Foundation хранится под управлением Subversion. Возможно, некоторым проектам ASF больше подошла бы какая-нибудь другая система контроля версий. Но Subversion — это единственная система контроля версий которая подходит всем проектам.

И когда идет речь о корпоративном использовании, когда одна система должна удовлетворять очень широкий спектр потребностей, Subversion оказывается вне конкуренции. Конечно, у Subversion есть альтернативы, например Perforce. Но Perforce это закрытый коммерческий продукт, у которого, кстати, совсем другая стоимость владения.

Плюс система контроля версий, это не просто exe. Для современной системы контроля версий важна развитая экосистема. Должны быть клиенты для всех операционных систем, должна быть интеграция в разные IDE, должна быть поддержка со стороны систем непрерывной интеграции и баг-треккеров. Благодаря Apache-вской BSD-style лицензии у Subversion очень развитая экосистема. Потому что лицензия Subversion позволяет разрабатывать коммерческие продукты без риска быть распятым GPL-фанатиками.

Можем ли мы сейчас ждать чего-то нового от Subversion?
Я думаю, что в следующем релизе будет наконец-то решена одна из последних фундаментальных проблем Subversion, связанная с обработкой переименований файлов и папок во время слияния веток. Это очень нетривиальная проблема, но сейчас идет активная работа по её решению. Потом, возможно, в каком-то виде появятся offline-коммиты. Но при этом совершенно точно можно сказать, что из Subversion не будут пытаться сделать распределенную систему контроля версий.

А преимущества есть какие-нибудь у Subversion по сравнению с git?
Вообще — вся эта история с Git тянет на звание IT-аферы века. Git это пример очень классного PR, который мало соответствует реальности. Я искренне восхищаюсь талантом Торвальдса как маркетолога и оратора. Но с технической точки зрения, Subversion и Git нельзя сравнивать. Subversion — это совсем другая глубина технической проработанности продукта и управляемости проекта.

Например в Git вообще нет операции переименования файлов и директорий. А для создания ощущения, что все в порядке, используют эвристический алгоритм по анализу содержимого файлов. Это работает для простых ситуаций, но может приводить к проблемам при реальном использовании.

Теперь становится понятно, почему Sun не стал использовать git для Java в своё время. Можешь сказать пару слов о Mercurial?
Я не эксперт по Mercurial, но могу сказать, что технически в нем есть несколько хороших идей. Если бы я выбирал распределенную систему управления версиями, то я бы скорее всего выбрал Mercurial, хотя и он под GPL.

Вы набираете?
Да, но в отношении сотрудников мы следуем принципу «лучше меньше, да лучше».