Комментарии 94
хорошая статья, особенно для новичков в сабвёржне
Наверное правильнее было бы разместить эту статью в блоге "Разработка".
Все-таки статья больше посвящена организации процесса, чем самому процессу.
Процесс - это положения: какую систему контроля версий использовать в проекте, порядок получения прав к VCS, порядок бренчевания и мерджинга.
Ответ на вопрос, что позволяет делать тот или иной инструмент, к процессу отношения не имеет.
Ответ на вопрос, что позволяет делать тот или иной инструмент, к процессу отношения не имеет.
НЛО прилетело и опубликовало эту надпись здесь
Versions, конечно, зачетная штука. Еше и с репозиторием
ИМХО - ни о чём....
почему-то западные "специалисты" любят разводить такой трёп.
Перевод хороший, но лучше заниматься переводом мануалов чем такой ерунды.
почему-то западные "специалисты" любят разводить такой трёп.
Перевод хороший, но лучше заниматься переводом мануалов чем такой ерунды.
Полностью с вами согласен, в последнее время хорошие статьи отыскать становится все труднее. Текст выбрал практически наобум, для пробы в переводе. Но надеюсь, кому-то может быть полезен.
Пожалуй, соглашусь. Очень много воды и очень мало по существу. Текст вправе претендовать на вступление к статье, но на саму статью, при всем уважении к автору и переводчику, ну никак не тянет.
Интересная тема. Как раз сейчас разбираюсь с этим делом.
Хотелось бы более подробного описания использования инструментов для решения задач.
И по самой статье насчет ожиданий:
Я считаю, что коммиты должны быть не "каждый час" или "после каждых 100 строк код", а логически целостными: то есть решил какую-то задачу (пусть даже исправил важную ошибку всего в одной строке) — закоммить и прокомментрируй что сделал. В этом случае процесс разработки будет представлять собой последовательность целостных шагов. В последствии может оказаться так, что какие-то шаги были ошибочными, их можно будет откатить. А если коммит делался абы когда зато по графику, чтобы показать активную работу, то шаги и откаты будут бредовые.
Ну и считается полезным коммитить к конце рабочего дня. Из тех же соображений, что элементарная задача не должна занимать больше 8 часов.
Хотелось бы более подробного описания использования инструментов для решения задач.
И по самой статье насчет ожиданий:
Я считаю, что коммиты должны быть не "каждый час" или "после каждых 100 строк код", а логически целостными: то есть решил какую-то задачу (пусть даже исправил важную ошибку всего в одной строке) — закоммить и прокомментрируй что сделал. В этом случае процесс разработки будет представлять собой последовательность целостных шагов. В последствии может оказаться так, что какие-то шаги были ошибочными, их можно будет откатить. А если коммит делался абы когда зато по графику, чтобы показать активную работу, то шаги и откаты будут бредовые.
Ну и считается полезным коммитить к конце рабочего дня. Из тех же соображений, что элементарная задача не должна занимать больше 8 часов.
В конце рабочего дня коммитить надо, потому что кто-то может раньше прийти на работу завтра, в выходной выйти поработать из дома или клиент захочет последние изменения посмотреть или еще что-то. Вряд ли тут зависит от времени выполнения задачи.
Правильно говорите. Коммит всегда должен закрывать какой-то таск. Т.е. лучше когда в репозитории рабочая версия, которая по крайне мере компилируется. Чтобы в любой момент, любой участник проекта, мог получить и собрать версию. Также есть такое понятие, как continues builds, т.е. билд сервер проверяет check-in'ы и строит очередную версию. Далее на эту версию запускаются юнит тесты. Мы правда работаем под MS Team System, но суть не меняется.
если пользоватся Гитом а не Сабвершином - то проблема слишком длинных таском решается отдельным бранчем, в который делаются коммиты, и который впоследствии сливается с основным репозиторием.
Вообще-то эта проблема точно так же решается даже если пользоваться сабвершеном.
по сути да... в жизни же я редко видел когда бы люди делали бранчи в сабвершине - разве что для очень длительных сторонних разработок... в гите же все для этого предназначено
У меня сложилось впечатление, что люди боятся делать бранчи потому, что думают, что это долго/накладно.
Вы удивитесь...
Когда мне потребовалось внести большие изменения в проект (в котором я единственный разработчик) я сделал отдельную ветку, все сделал, протестил и потом слил с основной.
Вопрос: нафига такие мучения?
Во-первых, это оказалось совсем несложно - merge и все ок.
Во-вторых, изменения заняли порядком времени, параллельно в основной ветке я решал основные рабочие задачи (которые нужно было сделать к определенному сроку). Если бы я делал все одновременно, то получил бы жуткую кашу в проекте и проблемы с работоспособностью в переходный период.
Когда мне потребовалось внести большие изменения в проект (в котором я единственный разработчик) я сделал отдельную ветку, все сделал, протестил и потом слил с основной.
Вопрос: нафига такие мучения?
Во-первых, это оказалось совсем несложно - merge и все ок.
Во-вторых, изменения заняли порядком времени, параллельно в основной ветке я решал основные рабочие задачи (которые нужно было сделать к определенному сроку). Если бы я делал все одновременно, то получил бы жуткую кашу в проекте и проблемы с работоспособностью в переходный период.
вы круты. а мне вот в свн как-то в лом бранчить од.. как вспомню все что этому сопутствует... ну не предназначен свн для быстрых и удобных бранчей и слияний
STALKER разрабатывали как раз с использованием SVN. Жаль они не могут высказать свое мнение по этому поводу основанное на практике
Честно говоря, я это тоже 1 раз использовал, когда был риск поломать проект.
Но все же мне не показалось это настолько сложным: вначале copy, а потом merge. Или у вас возникали конфликты при слиянии веток? В этом плане у меня ситуация проще.
Но все же мне не показалось это настолько сложным: вначале copy, а потом merge. Или у вас возникали конфликты при слиянии веток? В этом плане у меня ситуация проще.
НЛО прилетело и опубликовало эту надпись здесь
влом сливать в финале и резловить все конфликты, да еще и постоянно апдейтить содержимое моего бранча к основному коду.
я умом вроде понимаю что ничего тут страшного нет, и что это хорошо и правильно. Наверное просто был отрицательный опыт который не хочется повторять.
я умом вроде понимаю что ничего тут страшного нет, и что это хорошо и правильно. Наверное просто был отрицательный опыт который не хочется повторять.
вы несколько упрощаете. Сделать бранч действительно одна команда, а вот мерджить до версии 1.5 было не настолько просто, особенно если ветка развивается в паралель тому, на что вы мерджите и вы делаете эти слияния постоянно. Да и в 1.5 до того как мердж завершен, надо немало работы контрольной проделать. Обычно делается dry-run, потом смотрится собственно diff, делается собственно слияние, резолвятся конфликты (если возникли) а уж потом все это дело коммитится. И как я вижу наблюдая окружающих меня программеров, многим все это кажется слишком хлопотно, хотя я сам приверженец всей этой магии :)
Раз уж вы интересуетесь как раз сейчас, может быть вам поможет статья со сравнением существующих систем контроля версий
http://en.wikipedia.org/wiki/Comparison_of_revision_control_software
http://en.wikipedia.org/wiki/Comparison_of_revision_control_software
SVN надо пользоваться в команде, без него никак, поэтому если решились взяться за него, то все здесь:
http://www.collab.net/downloads/subversi… - сервер и консольный клиент
http://tortoisesvn.tigris.org/ - визуальный клиент под винду
А также многие IDE поддерживают работу с сервером.
http://www.collab.net/downloads/subversi… - сервер и консольный клиент
http://tortoisesvn.tigris.org/ - визуальный клиент под винду
А также многие IDE поддерживают работу с сервером.
А можно в двух словах, что дает Warehouse ?
Я как раз подбираю средство для удобного просмотра репозитария и упрвления багами. Пока хочу попробовать Trac.
По описанию очень похожий инструмент. В чем его преимущество?
Я как раз подбираю средство для удобного просмотра репозитария и упрвления багами. Пока хочу попробовать Trac.
По описанию очень похожий инструмент. В чем его преимущество?
Советую посмотреть на redmine (redmine.org) - отличная интеграция с Subversion. В нём намного проще управлять пользователями.
Спасибо. Симпатичная вещь и вроде как лучше русифицирован.
Понравилось наличие календаря и встроенного Ганта, только последний показался крайне сложным в поддержании адекватной структуры задач.
А какие еще аналоги знаете, чтобы можно было сравнить и подобрать для себя оптимум?
Понравилось наличие календаря и встроенного Ганта, только последний показался крайне сложным в поддержании адекватной структуры задач.
А какие еще аналоги знаете, чтобы можно было сравнить и подобрать для себя оптимум?
А что собственно вам надо - просмотр репозитария или управление багами ? ;)
Мы используем в качестве багтрекера Atlassian JIRA. Очень, очень навороченный продукт
(легко настраиваемый впрочем).
Есть интеграция с SVN - можно в коммитах забивать номера карточек
и собственно в карточках просматривать чего там девелоперы накоммитили.
Посмотрите, триал-версия полностью функциональна и разворачивается на раз.
Мы используем в качестве багтрекера Atlassian JIRA. Очень, очень навороченный продукт
(легко настраиваемый впрочем).
Есть интеграция с SVN - можно в коммитах забивать номера карточек
и собственно в карточках просматривать чего там девелоперы накоммитили.
Посмотрите, триал-версия полностью функциональна и разворачивается на раз.
А мне казалось, что каждый хабрачеловек уже знает, что такое сабвершан и использует ее. Наверное нет особого смысла давать здесь такие общие описания столь известных и популярных систем.
Предложил бы еще один полезный инструмент — скрипт post-commit, рассылающий уведомления по всем задействованным в проекте с подробной информацией кто, зачем внес изменения + diff. Таким образом все в курсе последних изменений в проекте, ну и менеджер видит как продвигается работа :)
Используйте SVN-Notify http://search.cpan.org/dist/SVN-Notify/ то что доктор прописал!
расскажи, как убедить разработчиков писать развернутые комментарии к чекинам :)
Попросите их рассказать новому разработчику про коммиты :)
На самом деле написать подробный комментарий требует на 1 минуту больше, а вспомнить через полгода зачем ты это сделал - минут 15 :)
На самом деле написать подробный комментарий требует на 1 минуту больше, а вспомнить через полгода зачем ты это сделал - минут 15 :)
Поставьте pre-commit hook, который проверяет длину комментария :) Ну или просто бейте по рукам тех, кто ленится писать подробно.
Развернутый комментарий не обязателен, часто достаточно привязки к логу задачи в таск-трекере (если компания больше 10 человек, таск-трекер должен быть).
Т.е. не требовать развернутого комментария в момент коммита, пусть пишет «Task 1235» (а это проверяется регэкспом хук-скрипта на pre-commit), а суть изменений фиксирует в логе задачи. Тогда становится легко по каждой задаче вытащить список ревизий и даже патч.
Т.е. не требовать развернутого комментария в момент коммита, пусть пишет «Task 1235» (а это проверяется регэкспом хук-скрипта на pre-commit), а суть изменений фиксирует в логе задачи. Тогда становится легко по каждой задаче вытащить список ревизий и даже патч.
а мне при слове "распределенной" сразу же мерещится Git
К сожалению до сих пор очень мало IDE под Windows поддерживают SVN(а то и CVS даже нет). Приходится работать через программы типа tortoisesvn. А это иногда не удобно.
Эх.. ещё бы сделали что-нибудь подобное для БД....
Эх.. ещё бы сделали что-нибудь подобное для БД....
НЛО прилетело и опубликовало эту надпись здесь
Спасибо за статью! Очень полезный инструмент в хозяйстве.
Кстати, сомневающимся очень рекомендую попробовать http://www.assembla.com. Там в свободное пользование можно получить готовый к работе SVN репозиторий + Track + вики + систему нотификаций — готовая площадка для ведения проекта небольшого-среднего размера.
А чё так отстаём. Почему об устаревшей SVN, а не о распределённых системах контроля версий (Git, Mercurial, Bazaar)?
распределённые системы - это тоже не панацея, мало того использование таких систем контроля версий, к примеру, усложняет возможность continuous integration
Ну кому-то интересует, почему SVN уже никогда не устареет, и чем она будет лучше любой распределенной системы контроля версий, то см. серию статей (переводов) на эту тему.
SVN интересная вещ для начинающих разработчиков и просто программистов. У Вас есть обзор инструментов для простого поднятия сервера под CentOS или Win?
SVN это вещь дико необходимоя, уже не представляю разрабодку без нее...
Единственное что не удаеться решить с ее помощью - это синхронизацыю бд между разработчиками. Писать в комментариях при коммитах sql-запросы всеже не очень удобно.
Может есть у кого опыт решения подобной проблеммы?
Единственное что не удаеться решить с ее помощью - это синхронизацыю бд между разработчиками. Писать в комментариях при коммитах sql-запросы всеже не очень удобно.
Может есть у кого опыт решения подобной проблеммы?
Можно модель базы хранить в репозитории и при коммитах указывать ревижн модели базы, который необходимо применить на данный ревижн.
Можно вести историю изменений базы в SQL-скриптах и в коммитах кода давать номера ревижнов, которые надо применить.
Это скорее не технологическая а административная проблема :)
Можно вести историю изменений базы в SQL-скриптах и в коммитах кода давать номера ревижнов, которые надо применить.
Это скорее не технологическая а административная проблема :)
НЛО прилетело и опубликовало эту надпись здесь
Для PostgreSQL есть отличная тулза - apgdiff.
Умеет сравнивать структуры двух баз по дампам и выдавать «патч» — sql-скрипт, применив который, вы приведете базу к нужной структуре.
Если бы еще прикрутить ее ввиду плагина к SVN, чтобы можно было получать такие патчики.
Умеет сравнивать структуры двух баз по дампам и выдавать «патч» — sql-скрипт, применив который, вы приведете базу к нужной структуре.
Если бы еще прикрутить ее ввиду плагина к SVN, чтобы можно было получать такие патчики.
Опыт использования подобных инструментов для Oracle - весьма отрицательный
для баз со сложной структурой (~1000 таблиц,~500 вьюх и огромное количество API-шных пакетов).
Причём, зачастую приходится отслеживать не только структуры - но и сами данные
(метаинфа, классификаторы и справочники).
В таких случаях спасает только внесение изменений базы в отдельную ветку репозитория(SQL-скрипты с изменениями относительно пустой модели данных или же дампы)
для баз со сложной структурой (~1000 таблиц,~500 вьюх и огромное количество API-шных пакетов).
Причём, зачастую приходится отслеживать не только структуры - но и сами данные
(метаинфа, классификаторы и справочники).
В таких случаях спасает только внесение изменений базы в отдельную ветку репозитория(SQL-скрипты с изменениями относительно пустой модели данных или же дампы)
Есть замечательная программа EMS Database Comparer http://www.sqlmanager.net/en/products
В наличии версии для MySQL, SQL Server, PostgreSQL, InterBase/Firebird, Oracle и DB2
Выводит все различия между базами и сразу предлагает изменения в виде sql-запросов.
В наличии версии для MySQL, SQL Server, PostgreSQL, InterBase/Firebird, Oracle и DB2
Выводит все различия между базами и сразу предлагает изменения в виде sql-запросов.
Все, советующие всякого рода дбкомпареры - ответьте пожалуйста на один простой вопрос:
Как вы предлагаете использовать эти утилиты в случае если база-источник изменений в одном городе
а базы-потребители - в других? ;)
Как вы предлагаете использовать эти утилиты в случае если база-источник изменений в одном городе
а базы-потребители - в других? ;)
Расположение баз не имеет значения. Программа может подключаться удаленно по SSH.
уже давно практикуем trac+subversion, даже менеджеры могут узнать о текущих планах :)
Разве слово control, в данном случае, не уместнее переводить как "управление"?
Система управления версиями. При чём тут "контроль"?
Система управления версиями. При чём тут "контроль"?
Вообще, принципиальной разницы нет, хотя в википедии используется именно «управление». Но и «контроль» тоже часто употребляется.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Совместная разработка с помощью Subversion