Pull to refresh
Comments 94
Наверное правильнее было бы разместить эту статью в блоге "Разработка".
Все-таки статья больше посвящена организации процесса, чем самому процессу.
Процесс - это положения: какую систему контроля версий использовать в проекте, порядок получения прав к VCS, порядок бренчевания и мерджинга.

Ответ на вопрос, что позволяет делать тот или иной инструмент, к процессу отношения не имеет.
Все таки останусь при своём мнении насчет расположения топика, да и на ALA он имеет теги Business, Project Management and Workflow.
Проблема в том, что Subversion вообще не нужен руководителям проектов, не связанных с разработкой кода (дизайн, строительство, маркетинг). Он нужен разработчикам, и лишь иногда некоторым менеджерам.
UFO landed and left these words here
Да, и помоему в документации на русском даже о возвышенном написано больше и ярче :) Да простит меня переводчик...
Versions, конечно, зачетная штука. Еше и с репозиторием
ИМХО - ни о чём....
почему-то западные "специалисты" любят разводить такой трёп.
Перевод хороший, но лучше заниматься переводом мануалов чем такой ерунды.
Полностью с вами согласен, в последнее время хорошие статьи отыскать становится все труднее. Текст выбрал практически наобум, для пробы в переводе. Но надеюсь, кому-то может быть полезен.
Пожалуй, соглашусь. Очень много воды и очень мало по существу. Текст вправе претендовать на вступление к статье, но на саму статью, при всем уважении к автору и переводчику, ну никак не тянет.
Интересная тема. Как раз сейчас разбираюсь с этим делом.
Хотелось бы более подробного описания использования инструментов для решения задач.

И по самой статье насчет ожиданий:
Я считаю, что коммиты должны быть не "каждый час" или "после каждых 100 строк код", а логически целостными: то есть решил какую-то задачу (пусть даже исправил важную ошибку всего в одной строке) — закоммить и прокомментрируй что сделал. В этом случае процесс разработки будет представлять собой последовательность целостных шагов. В последствии может оказаться так, что какие-то шаги были ошибочными, их можно будет откатить. А если коммит делался абы когда зато по графику, чтобы показать активную работу, то шаги и откаты будут бредовые.
Ну и считается полезным коммитить к конце рабочего дня. Из тех же соображений, что элементарная задача не должна занимать больше 8 часов.
В конце рабочего дня коммитить надо, потому что кто-то может раньше прийти на работу завтра, в выходной выйти поработать из дома или клиент захочет последние изменения посмотреть или еще что-то. Вряд ли тут зависит от времени выполнения задачи.
Угу. Просто хочется, чтобы коммит в первую очередь был осмысленным. Т.к. наврядли половинчатые изменения кому-нибудь помогут. Скорее еще больше запутают.
пришел кто-то завтра пораньше на работу - а код не компилится, потому что задачу я не доделал, зато все коммитнул.
Правильно говорите. Коммит всегда должен закрывать какой-то таск. Т.е. лучше когда в репозитории рабочая версия, которая по крайне мере компилируется. Чтобы в любой момент, любой участник проекта, мог получить и собрать версию. Также есть такое понятие, как continues builds, т.е. билд сервер проверяет check-in'ы и строит очередную версию. Далее на эту версию запускаются юнит тесты. Мы правда работаем под MS Team System, но суть не меняется.
У нас примерно так же сделано. У каждого своя рабочая версия, после решения очередно задачи коммит на сервер. В итоге trunk хоть как-то, но работоспособен. Снижается риск, что у других разработчиков после апдейта все поломается.
если пользоватся Гитом а не Сабвершином - то проблема слишком длинных таском решается отдельным бранчем, в который делаются коммиты, и который впоследствии сливается с основным репозиторием.
Вообще-то эта проблема точно так же решается даже если пользоваться сабвершеном.
по сути да... в жизни же я редко видел когда бы люди делали бранчи в сабвершине - разве что для очень длительных сторонних разработок... в гите же все для этого предназначено
У меня сложилось впечатление, что люди боятся делать бранчи потому, что думают, что это долго/накладно.
так все и есть, зато в гите - все заточено под бранчи да слияния - там сама система настаивает на них, и словно направляет разработчиков на правильный путь )
Вы удивитесь...
Когда мне потребовалось внести большие изменения в проект (в котором я единственный разработчик) я сделал отдельную ветку, все сделал, протестил и потом слил с основной.
Вопрос: нафига такие мучения?
Во-первых, это оказалось совсем несложно - merge и все ок.
Во-вторых, изменения заняли порядком времени, параллельно в основной ветке я решал основные рабочие задачи (которые нужно было сделать к определенному сроку). Если бы я делал все одновременно, то получил бы жуткую кашу в проекте и проблемы с работоспособностью в переходный период.
вы круты. а мне вот в свн как-то в лом бранчить од.. как вспомню все что этому сопутствует... ну не предназначен свн для быстрых и удобных бранчей и слияний
STALKER разрабатывали как раз с использованием SVN. Жаль они не могут высказать свое мнение по этому поводу основанное на практике
Честно говоря, я это тоже 1 раз использовал, когда был риск поломать проект.
Но все же мне не показалось это настолько сложным: вначале copy, а потом merge. Или у вас возникали конфликты при слиянии веток? В этом плане у меня ситуация проще.
когда над кодом работает команда, то конфликты всегда возникают...
А когда команда пользуется Git'ом, конфликты что-ли не возникают?
А я вот не понимаю, хоть убей, что там может быть "в лом". Сделать бранч - одна(!) команда. Слить - тоже одна команда. А вот если накосячить в единственной разрабатываемой ветке - вот это да, это будет геморрой конкретный.
влом сливать в финале и резловить все конфликты, да еще и постоянно апдейтить содержимое моего бранча к основному коду.

я умом вроде понимаю что ничего тут страшного нет, и что это хорошо и правильно. Наверное просто был отрицательный опыт который не хочется повторять.
влом сливать в финале и резловить все конфликты, да еще и постоянно апдейтить содержимое моего бранча к основному коду.
Если вы будете постоянно мержить транк в свой бранч, то конфликтов при мерже бранча назад в транк у вас быть не должно.
Это не всегда возможно. Например, при рефакторинге,
когда меняются интерфейсы\слои.
вы несколько упрощаете. Сделать бранч действительно одна команда, а вот мерджить до версии 1.5 было не настолько просто, особенно если ветка развивается в паралель тому, на что вы мерджите и вы делаете эти слияния постоянно. Да и в 1.5 до того как мердж завершен, надо немало работы контрольной проделать. Обычно делается dry-run, потом смотрится собственно diff, делается собственно слияние, резолвятся конфликты (если возникли) а уж потом все это дело коммитится. И как я вижу наблюдая окружающих меня программеров, многим все это кажется слишком хлопотно, хотя я сам приверженец всей этой магии :)
Раз уж вы интересуетесь как раз сейчас, может быть вам поможет статья со сравнением существующих систем контроля версий
http://en.wikipedia.org/wiki/Comparison_of_revision_control_software
SVN надо пользоваться в команде, без него никак, поэтому если решились взяться за него, то все здесь:
http://www.collab.net/downloads/subversi… - сервер и консольный клиент
http://tortoisesvn.tigris.org/ - визуальный клиент под винду
А также многие IDE поддерживают работу с сервером.
VCS стОит пользоваться, даже если вы — маньяк-одиночка.
А можно в двух словах, что дает Warehouse ?
Я как раз подбираю средство для удобного просмотра репозитария и упрвления багами. Пока хочу попробовать Trac.

По описанию очень похожий инструмент. В чем его преимущество?
Советую посмотреть на redmine (redmine.org) - отличная интеграция с Subversion. В нём намного проще управлять пользователями.
Спасибо. Симпатичная вещь и вроде как лучше русифицирован.
Понравилось наличие календаря и встроенного Ганта, только последний показался крайне сложным в поддержании адекватной структуры задач.
А какие еще аналоги знаете, чтобы можно было сравнить и подобрать для себя оптимум?
А что собственно вам надо - просмотр репозитария или управление багами ? ;)

Мы используем в качестве багтрекера Atlassian JIRA. Очень, очень навороченный продукт
(легко настраиваемый впрочем).
Есть интеграция с SVN - можно в коммитах забивать номера карточек
и собственно в карточках просматривать чего там девелоперы накоммитили.
Посмотрите, триал-версия полностью функциональна и разворачивается на раз.
А мне казалось, что каждый хабрачеловек уже знает, что такое сабвершан и использует ее. Наверное нет особого смысла давать здесь такие общие описания столь известных и популярных систем.
Я только год работаю в этой сфере (программирование)и, к сожаленью, еще не использовал( Сейчас уже примерно месяц думаю начать, но не знаю с чего. Я был бы очень рад, если бы кто-нибудь написал статью о начале работы с SVN (что установить, как использовать). Если кому-нибудь не сложно - напишите.
Об этом уже давно написано. Почитайте svnbook, она даже на русский переведена (правда для версии 1.4, но в вашем случае это не так уж важно).
Предложил бы еще один полезный инструмент — скрипт post-commit, рассылающий уведомления по всем задействованным в проекте с подробной информацией кто, зачем внес изменения + diff. Таким образом все в курсе последних изменений в проекте, ну и менеджер видит как продвигается работа :)
расскажи, как убедить разработчиков писать развернутые комментарии к чекинам :)
Попросите их рассказать новому разработчику про коммиты :)
На самом деле написать подробный комментарий требует на 1 минуту больше, а вспомнить через полгода зачем ты это сделал - минут 15 :)
Поставьте pre-commit hook, который проверяет длину комментария :) Ну или просто бейте по рукам тех, кто ленится писать подробно.
Развернутый комментарий не обязателен, часто достаточно привязки к логу задачи в таск-трекере (если компания больше 10 человек, таск-трекер должен быть).
Т.е. не требовать развернутого комментария в момент коммита, пусть пишет «Task 1235» (а это проверяется регэкспом хук-скрипта на pre-commit), а суть изменений фиксирует в логе задачи. Тогда становится легко по каждой задаче вытащить список ревизий и даже патч.
а мне при слове "распределенной" сразу же мерещится Git
Дык не используем... пока SVN хвататет.
Но надо понять в чем его кардинальные преимущества лично для нас.
К сожалению до сих пор очень мало IDE под Windows поддерживают SVN(а то и CVS даже нет). Приходится работать через программы типа tortoisesvn. А это иногда не удобно.

Эх.. ещё бы сделали что-нибудь подобное для БД....
Работайте с SVN через командную строку. Там графика ни к чему совершенно.
Могу. Ihmo diff-ать удобнее НЕ из командной строки ;)
Мержить в ручном режиме тоже.
В Eclipse например очень удобно смотреть диффы, ну и видно сразу в дереве, какой файл в каком состоянии.
UFO landed and left these words here
Наверное, если ваша IDE все еще не научилась SVN, ее надо сменить на что-то современное. Практически все современные IDE могут работать с SVN как минимум после установки плагина.
UFO landed and left these words here
Как запущен svnserve? standalone или через inetd? не пытается ли svnserve резольвить IP-адреса клиентов? У вас настроена локальная DNS-зона?
UFO landed and left these words here
Спасибо за статью! Очень полезный инструмент в хозяйстве.
Кстати, сомневающимся очень рекомендую попробовать http://www.assembla.com. Там в свободное пользование можно получить готовый к работе SVN репозиторий + Track + вики + систему нотификаций — готовая площадка для ведения проекта небольшого-среднего размера.
А чё так отстаём. Почему об устаревшей SVN, а не о распределённых системах контроля версий (Git, Mercurial, Bazaar)?
распределённые системы - это тоже не панацея, мало того использование таких систем контроля версий, к примеру, усложняет возможность continuous integration
SVN интересная вещ для начинающих разработчиков и просто программистов. У Вас есть обзор инструментов для простого поднятия сервера под CentOS или Win?
SVN это вещь дико необходимоя, уже не представляю разрабодку без нее...
Единственное что не удаеться решить с ее помощью - это синхронизацыю бд между разработчиками. Писать в комментариях при коммитах sql-запросы всеже не очень удобно.
Может есть у кого опыт решения подобной проблеммы?
Можно модель базы хранить в репозитории и при коммитах указывать ревижн модели базы, который необходимо применить на данный ревижн.

Можно вести историю изменений базы в SQL-скриптах и в коммитах кода давать номера ревижнов, которые надо применить.
Это скорее не технологическая а административная проблема :)
Ruby On Rails, например, решают эту проблему с помощью Migrations. Но почему-то эта практика не получила распространения в других фреймворках :)

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

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

Причём, зачастую приходится отслеживать не только структуры - но и сами данные
(метаинфа, классификаторы и справочники).
В таких случаях спасает только внесение изменений базы в отдельную ветку репозитория(SQL-скрипты с изменениями относительно пустой модели данных или же дампы)
Есть замечательная программа EMS Database Comparer http://www.sqlmanager.net/en/products
В наличии версии для MySQL, SQL Server, PostgreSQL, InterBase/Firebird, Oracle и DB2
Выводит все различия между базами и сразу предлагает изменения в виде sql-запросов.
Все, советующие всякого рода дбкомпареры - ответьте пожалуйста на один простой вопрос:
Как вы предлагаете использовать эти утилиты в случае если база-источник изменений в одном городе
а базы-потребители - в других? ;)
Расположение баз не имеет значения. Программа может подключаться удаленно по SSH.
ммм.
Imho какой то сомнительный способ синхронизации баз для использования
в качестве решения.
Как разовый вариант - не спорю, полезная фича.

И, сия тулза сравнивает структуры или может и данные сравнивать?
Только структуру.
Как вариант, я думаю, можно настроить репликацию.
Не вариант вообще.
Слишком много телодвижений и, как следствие,
бардак. Проще всё же не "тулзы" использовать
а написать регламент по порядку внесения изменений
в БД и следовать ему,
выкладывая изменяющей стороной дампы И/ИЛИ SQL-скрипты,
актуализующие состояние БД.
уже давно практикуем trac+subversion, даже менеджеры могут узнать о текущих планах :)
Разве слово control, в данном случае, не уместнее переводить как "управление"?
Система управления версиями. При чём тут "контроль"?
Вообще, принципиальной разницы нет, хотя в википедии используется именно «управление». Но и «контроль» тоже часто употребляется.
Only those users with full accounts are able to leave comments. Log in, please.