Совместная разработка с помощью Subversion

[@artemy_m]

хорошая статья, особенно для новичков в сабвёржне

[@A_Gura]

Наверное правильнее было бы разместить эту статью в блоге "Разработка".

[@nik]

Все-таки статья больше посвящена организации процесса, чем самому процессу.

[@A_Gura]

Процесс - это положения: какую систему контроля версий использовать в проекте, порядок получения прав к VCS, порядок бренчевания и мерджинга.

Ответ на вопрос, что позволяет делать тот или иной инструмент, к процессу отношения не имеет.

[@nik]

Все таки останусь при своём мнении насчет расположения топика, да и на ALA он имеет теги Business, Project Management and Workflow.

[@bratchuk]

Проблема в том, что Subversion вообще не нужен руководителям проектов, не связанных с разработкой кода (дизайн, строительство, маркетинг). Он нужен разработчикам, и лишь иногда некоторым менеджерам.

[@YuriyIlyin]

Да, и помоему в документации на русском даже о возвышенном написано больше и ярче :) Да простит меня переводчик...

[@nik]

Прощаю :)

[@grossu]

Versions, конечно, зачетная штука. Еше и с репозиторием

[@shandor]

ИМХО - ни о чём....
почему-то западные "специалисты" любят разводить такой трёп.
Перевод хороший, но лучше заниматься переводом мануалов чем такой ерунды.

[@nik]

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

[@albatross]

Пожалуй, соглашусь. Очень много воды и очень мало по существу. Текст вправе претендовать на вступление к статье, но на саму статью, при всем уважении к автору и переводчику, ну никак не тянет.

[@el777]

Интересная тема. Как раз сейчас разбираюсь с этим делом.
Хотелось бы более подробного описания использования инструментов для решения задач.

И по самой статье насчет ожиданий:
Я считаю, что коммиты должны быть не "каждый час" или "после каждых 100 строк код", а логически целостными: то есть решил какую-то задачу (пусть даже исправил важную ошибку всего в одной строке) — закоммить и прокомментрируй что сделал. В этом случае процесс разработки будет представлять собой последовательность целостных шагов. В последствии может оказаться так, что какие-то шаги были ошибочными, их можно будет откатить. А если коммит делался абы когда зато по графику, чтобы показать активную работу, то шаги и откаты будут бредовые.
Ну и считается полезным коммитить к конце рабочего дня. Из тех же соображений, что элементарная задача не должна занимать больше 8 часов.

[@FB3]

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

[@el777]

Угу. Просто хочется, чтобы коммит в первую очередь был осмысленным. Т.к. наврядли половинчатые изменения кому-нибудь помогут. Скорее еще больше запутают.

[@bogolt]

пришел кто-то завтра пораньше на работу - а код не компилится, потому что задачу я не доделал, зато все коммитнул.

[@vitaks]

Правильно говорите. Коммит всегда должен закрывать какой-то таск. Т.е. лучше когда в репозитории рабочая версия, которая по крайне мере компилируется. Чтобы в любой момент, любой участник проекта, мог получить и собрать версию. Также есть такое понятие, как continues builds, т.е. билд сервер проверяет check-in'ы и строит очередную версию. Далее на эту версию запускаются юнит тесты. Мы правда работаем под MS Team System, но суть не меняется.

[@el777]

У нас примерно так же сделано. У каждого своя рабочая версия, после решения очередно задачи коммит на сервер. В итоге trunk хоть как-то, но работоспособен. Снижается риск, что у других разработчиков после апдейта все поломается.

[@bogolt]

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

[@Paul]

Вообще-то эта проблема точно так же решается даже если пользоваться сабвершеном.

[@bogolt]

по сути да... в жизни же я редко видел когда бы люди делали бранчи в сабвершине - разве что для очень длительных сторонних разработок... в гите же все для этого предназначено

[@Paul]

У меня сложилось впечатление, что люди боятся делать бранчи потому, что думают, что это долго/накладно.

[@bogolt]

так все и есть, зато в гите - все заточено под бранчи да слияния - там сама система настаивает на них, и словно направляет разработчиков на правильный путь )

[@el777]

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

[@bogolt]

вы круты. а мне вот в свн как-то в лом бранчить од.. как вспомню все что этому сопутствует... ну не предназначен свн для быстрых и удобных бранчей и слияний

[@bethrezen]

STALKER разрабатывали как раз с использованием SVN. Жаль они не могут высказать свое мнение по этому поводу основанное на практике

[@el777]

Честно говоря, я это тоже 1 раз использовал, когда был риск поломать проект.
Но все же мне не показалось это настолько сложным: вначале copy, а потом merge. Или у вас возникали конфликты при слиянии веток? В этом плане у меня ситуация проще.

[@bogolt]

когда над кодом работает команда, то конфликты всегда возникают...

[@Paul]

А когда команда пользуется Git'ом, конфликты что-ли не возникают?

[@bogolt]

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

я умом вроде понимаю что ничего тут страшного нет, и что это хорошо и правильно. Наверное просто был отрицательный опыт который не хочется повторять.

[@Paul]

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

Если вы будете постоянно мержить транк в свой бранч, то конфликтов при мерже бранча назад в транк у вас быть не должно.

[@dmitryaxe]

Это не всегда возможно. Например, при рефакторинге,
когда меняются интерфейсы\слои.

[@umputun]

вы несколько упрощаете. Сделать бранч действительно одна команда, а вот мерджить до версии 1.5 было не настолько просто, особенно если ветка развивается в паралель тому, на что вы мерджите и вы делаете эти слияния постоянно. Да и в 1.5 до того как мердж завершен, надо немало работы контрольной проделать. Обычно делается dry-run, потом смотрится собственно diff, делается собственно слияние, резолвятся конфликты (если возникли) а уж потом все это дело коммитится. И как я вижу наблюдая окружающих меня программеров, многим все это кажется слишком хлопотно, хотя я сам приверженец всей этой магии :)

[@flashface]

Раз уж вы интересуетесь как раз сейчас, может быть вам поможет статья со сравнением существующих систем контроля версий
http://en.wikipedia.org/wiki/Comparison_of_revision_control_software

[@FB3]

SVN надо пользоваться в команде, без него никак, поэтому если решились взяться за него, то все здесь:
http://www.collab.net/downloads/subversi… - сервер и консольный клиент
http://tortoisesvn.tigris.org/ - визуальный клиент под винду
А также многие IDE поддерживают работу с сервером.

[@el777]

А можно в двух словах, что дает Warehouse ?
Я как раз подбираю средство для удобного просмотра репозитария и упрвления багами. Пока хочу попробовать Trac.

По описанию очень похожий инструмент. В чем его преимущество?

[@musuk]

Советую посмотреть на redmine (redmine.org) - отличная интеграция с Subversion. В нём намного проще управлять пользователями.

[@el777]

Спасибо. Симпатичная вещь и вроде как лучше русифицирован.
Понравилось наличие календаря и встроенного Ганта, только последний показался крайне сложным в поддержании адекватной структуры задач.
А какие еще аналоги знаете, чтобы можно было сравнить и подобрать для себя оптимум?

[@dmitryaxe]

А что собственно вам надо - просмотр репозитария или управление багами ? ;)

Мы используем в качестве багтрекера Atlassian JIRA. Очень, очень навороченный продукт
(легко настраиваемый впрочем).
Есть интеграция с SVN - можно в коммитах забивать номера карточек
и собственно в карточках просматривать чего там девелоперы накоммитили.
Посмотрите, триал-версия полностью функциональна и разворачивается на раз.

[@feedbee]

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

[@leonard]

Я только год работаю в этой сфере (программирование)и, к сожаленью, еще не использовал( Сейчас уже примерно месяц думаю начать, но не знаю с чего. Я был бы очень рад, если бы кто-нибудь написал статью о начале работы с SVN (что установить, как использовать). Если кому-нибудь не сложно - напишите.

[@Paul]

Об этом уже давно написано. Почитайте svnbook, она даже на русский переведена (правда для версии 1.4, но в вашем случае это не так уж важно).

[@leonard]

Спасибо)

[@feedbee]

Держите

[@leonard]

Спасибо большое.

[@el777]

Предложил бы еще один полезный инструмент — скрипт post-commit, рассылающий уведомления по всем задействованным в проекте с подробной информацией кто, зачем внес изменения + diff. Таким образом все в курсе последних изменений в проекте, ну и менеджер видит как продвигается работа :)

[@googol]

Используйте SVN-Notify http://search.cpan.org/dist/SVN-Notify/ то что доктор прописал!

[@lyxsus]

расскажи, как убедить разработчиков писать развернутые комментарии к чекинам :)

[@el777]

Попросите их рассказать новому разработчику про коммиты :)
На самом деле написать подробный комментарий требует на 1 минуту больше, а вспомнить через полгода зачем ты это сделал - минут 15 :)

[@Paul]

Поставьте pre-commit hook, который проверяет длину комментария :) Ну или просто бейте по рукам тех, кто ленится писать подробно.

[@lyxsus]

Отличная идея, спасибо.

[@belonesox]

Развернутый комментарий не обязателен, часто достаточно привязки к логу задачи в таск-трекере (если компания больше 10 человек, таск-трекер должен быть).
Т.е. не требовать развернутого комментария в момент коммита, пусть пишет «Task 1235» (а это проверяется регэкспом хук-скрипта на pre-commit), а суть изменений фиксирует в логе задачи. Тогда становится легко по каждой задаче вытащить список ревизий и даже патч.

[@bogolt]

а мне при слове "распределенной" сразу же мерещится Git

[@el777]

А как насчет Bazaar? :)

[@neithere]

А как насчет Mercurial? :)

[@el777]

Дык не используем... пока SVN хвататет.
Но надо понять в чем его кардинальные преимущества лично для нас.

[@neithere]

Значит, работает — не трогай =)

[@bethrezen]

К сожалению до сих пор очень мало IDE под Windows поддерживают SVN(а то и CVS даже нет). Приходится работать через программы типа tortoisesvn. А это иногда не удобно.

Эх.. ещё бы сделали что-нибудь подобное для БД....

[@bethrezen]

Вся суть в удобстве

[@bethrezen]

Eclipse SDK. Очень удобно работает с SVN

[@musuk]

Для VisualStudio есть SVNклиент.

[@dmitryaxe]

Могу. Ihmo diff-ать удобнее НЕ из командной строки ;)
Мержить в ручном режиме тоже.

[@feedbee]

Наверное, если ваша IDE все еще не научилась SVN, ее надо сменить на что-то современное. Практически все современные IDE могут работать с SVN как минимум после установки плагина.

[@mx2000]

Как запущен svnserve? standalone или через inetd? не пытается ли svnserve резольвить IP-адреса клиентов? У вас настроена локальная DNS-зона?

[@Treg]

Спасибо за статью! Очень полезный инструмент в хозяйстве.

[@Regis]

Кстати, сомневающимся очень рекомендую попробовать http://www.assembla.com. Там в свободное пользование можно получить готовый к работе SVN репозиторий + Track + вики + систему нотификаций — готовая площадка для ведения проекта небольшого-среднего размера.

[@el777]

Еще есть довольно симпатичный Acunote с весьма либеральными ценами.

[@Iskin]

А чё так отстаём. Почему об устаревшей SVN, а не о распределённых системах контроля версий (Git, Mercurial, Bazaar)?

[@alexsun]

распределённые системы - это тоже не панацея, мало того использование таких систем контроля версий, к примеру, усложняет возможность continuous integration

[@belonesox]

Ну кому-то интересует, почему SVN уже никогда не устареет, и чем она будет лучше любой распределенной системы контроля версий, то см. серию статей (переводов) на эту тему.

[@LDEV]

SVN интересная вещ для начинающих разработчиков и просто программистов. У Вас есть обзор инструментов для простого поднятия сервера под CentOS или Win?

[@studentpm]

SVN это вещь дико необходимоя, уже не представляю разрабодку без нее...
Единственное что не удаеться решить с ее помощью - это синхронизацыю бд между разработчиками. Писать в комментариях при коммитах sql-запросы всеже не очень удобно.
Может есть у кого опыт решения подобной проблеммы?

[@dmitryaxe]

Можно модель базы хранить в репозитории и при коммитах указывать ревижн модели базы, который необходимо применить на данный ревижн.

Можно вести историю изменений базы в SQL-скриптах и в коммитах кода давать номера ревижнов, которые надо применить.
Это скорее не технологическая а административная проблема :)

[@el777]

Для PostgreSQL есть отличная тулза - apgdiff.
Умеет сравнивать структуры двух баз по дампам и выдавать «патч» — sql-скрипт, применив который, вы приведете базу к нужной структуре.

Если бы еще прикрутить ее ввиду плагина к SVN, чтобы можно было получать такие патчики.

[@dmitryaxe]

Опыт использования подобных инструментов для Oracle - весьма отрицательный
для баз со сложной структурой (~1000 таблиц,~500 вьюх и огромное количество API-шных пакетов).

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

[@Treg]

Есть замечательная программа EMS Database Comparer http://www.sqlmanager.net/en/products
В наличии версии для MySQL, SQL Server, PostgreSQL, InterBase/Firebird, Oracle и DB2
Выводит все различия между базами и сразу предлагает изменения в виде sql-запросов.

[@dmitryaxe]

Все, советующие всякого рода дбкомпареры - ответьте пожалуйста на один простой вопрос:
Как вы предлагаете использовать эти утилиты в случае если база-источник изменений в одном городе
а базы-потребители - в других? ;)

[@Treg]

Расположение баз не имеет значения. Программа может подключаться удаленно по SSH.

[@dmitryaxe]

ммм.
Imho какой то сомнительный способ синхронизации баз для использования
в качестве решения.
Как разовый вариант - не спорю, полезная фича.

И, сия тулза сравнивает структуры или может и данные сравнивать?

[@Treg]

Только структуру.
Как вариант, я думаю, можно настроить репликацию.

[@dmitryaxe]

Не вариант вообще.
Слишком много телодвижений и, как следствие,
бардак. Проще всё же не "тулзы" использовать
а написать регламент по порядку внесения изменений
в БД и следовать ему,
выкладывая изменяющей стороной дампы И/ИЛИ SQL-скрипты,
актуализующие состояние БД.

[@Rbs]

уже давно практикуем trac+subversion, даже менеджеры могут узнать о текущих планах :)

[@dime]

Разве слово control, в данном случае, не уместнее переводить как "управление"?
Система управления версиями. При чём тут "контроль"?

[@nik]

Вообще, принципиальной разницы нет, хотя в википедии используется именно «управление». Но и «контроль» тоже часто употребляется.