LINUX.ORG.RU

Организация совместной разработки ПО на базе SVN+DocBook+Mantis: Часть 2, 3

 , , ,


0

2

Часть 2. Subversion - установка и администрирование сервера


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

  • посильна для любого программиста;
  • не требует значительных временных затрат;
  • требует организованности и методичности.


Одним из важнейших преимуществ Subversion является многоплатформенность, полная совместимость серверных и клиентских частей, работающих на разных платформах, удивительная простота установки серверной и клиентской частей и легкость администрирования. В статье будут рассматриваться вопросы в аспекте Linux (на примере OpenSUSE 11.2) и Windows XP.


Часть 3. Subversion - работа с версиями проекта


Мы знаем, что запущен сервер Subversion и нам предстоит начинать с ним работу в рамках определенного программного проекта, используя определенный метод доступа к хранилищу. Если создатель хранилища (администратор) создает хранилище исключительно используя прямой доступ (все команды администрирования выполняются без использования URL) непосредственно на компьютере где непосредственно расположено хранилище, то клиент может обращаться к серверу, расположенному:

  • на том же компьютере, что и рабочая копия;
  • на компьютере в локальной сети;
  • сервер доступен через Интернет.


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

>>> Подробности

★★★

Проверено: mono ()

Ответ на: комментарий от anonymous

> Разработчик может свой бранч так же загружать на удалённый сервер, его изменения никому не помешают, потому что это отдельный бранч.

А может и не загружать. В этом - минус dvcs.

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


Зачем тогда нужен локальный репозиторий?

Manhunt ★★★★★ ()
Ответ на: комментарий от Manhunt

> DVCS в нирвану в этой ситуации ушли бы не последние незафиксированные кусочи, а целые бранчи (с характерным размером в человекомесяц, например).

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

tailgunner ★★★★★ ()
Ответ на: комментарий от balodja

игра в ассоциации не для dvcs-фагов.

anonymous ()
Ответ на: комментарий от tailgunner

Вот именно. SVN это быстро. Потому что простой, как валенок, и разобраться в работе, быстро применить, быстро использовать его можно очень быстро. C круче, Python проще. Вот и вся редиска. Или петрушка.

debian6 ()
Ответ на: комментарий от debian6

И интегрировать в другой продукт например. Скрытым от пользователя продукта способом.

anonymous ()
Ответ на: комментарий от Manhunt

> А может и не загружать. В этом - минус dvcs.

Ага, а ещё можно месяц не commit-ить — что-то я не вижу принципиальной разницы с svn

Зачем тогда нужен локальный репозиторий?

Быстрый log / annotate, хорошие годные мержи.

Я не утверждаю, что для централизованной VCS нельзя сделать хороший мержер.

я опираюсь на конкретные воплощения разных подходов такие как svn с одной стороны и git / hg с другой.

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

anonymous ()
Ответ на: комментарий от anonymous

> Так вот среди этих конкретных программ способностью к удобному и быстрому созданию и слиянию веток обладают только DVCS системы.

не везде нужно создавать и сливать ветки.

anonymous ()
Ответ на: комментарий от anonymous

> не везде нужно создавать и сливать ветки.

Ага, а ещё не везде нужна история. Ну ты понял ;-)

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

anonymous ()
Ответ на: комментарий от anonymous

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

Весь мир только и крутиться вокруг разработчиков.

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

anonymous ()
Ответ на: комментарий от anonymous

> Весь мир только и крутиться вокруг разработчиков.

Смотрим в заголовок темы и видим... внезапно, «Организация совместной разработки ПО». Хочешь поговорить об использовании VCS в бизнесе - нет проблем, но мир и вокруг бизнеса тоже не крутится.

tailgunner ★★★★★ ()
Ответ на: комментарий от debian6

> SVN это быстро. Потому что простой, как валенок, и разобраться в работе,

Еще раз, медленно и печально: для персонального использования в режиме SVN тот же Mercurial не сложнее SVN (Git, конечно, другое дело). Для группового - может быть, сложнее. Но может быть, и нет (если не углубляться в вещи типа rebase и mq).

tailgunner ★★★★★ ()
Ответ на: комментарий от anonymous

> Весь мир только и крутиться вокруг разработчиков.

Про гуманитариев и офисный планктон никто и не спорит.

Пусть используют хоть Microsoft®™ SharePoint®­™

Для разработки ПО лучше подходит DVCS.

anonymous ()
Ответ на: комментарий от tailgunner

Весь мир только и крутиться вокруг разработчиков.

Смотрим в заголовок темы и видим... внезапно, «Организация совместной разработки ПО».

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

shty ★★★★★ ()
Ответ на: комментарий от shty

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

(1) Скорость (в первую очередь из-за локальности большинства операций)

(2) Эффективный бранч/мерж с наглядной историей

(3) Возможность использовать разные рабочие процессы в зависимости от нужд проекта: http://progit.org/book/ch5-1.html

(4) Различные маленькие удобности такие как git stash / hg shelve, stgit / mercurial queues, описывать долго, можешь сам нагуглить.

anonymous ()
Ответ на: комментарий от shty

> есть такая подобласть «разработки ПО» как «разработка игрового ПО» (к примеру)

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

anonymous ()
Ответ на: комментарий от tailgunner

Пошёл учить mercurial. Но если что не так, знай, что она тебе прибъёт. Она как бы эта ... как её там ... в общем, я сам боюсь.

debian6 ()
Ответ на: комментарий от tailgunner

>Как тут помог бы SVN?

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

kraw ★★★★ ()
Ответ на: комментарий от tailgunner

>И причем тут пункты: «бэкап» и «сбор статистики» (первое всё равно надо делать для машин пользователей, для второго существуют центральные репозитории)

Притом, что в случае svn это делается гораздо проще и дешевле. Что очень важно в случае небольшого некоммерческого проекта.

Вот в моем случае, нашел бесплатный хостинг, завел там репозиторий. Показал другим разработчикам (которые вообще в первый раз о контроле версий услышали) как и когда надо делать checkout, commit и update. Завел зеркало на домашнем компе. И все. Никаких дополнительных затрат времени и сил.

В чем был бы мой выигрыш, если бы я выбрал DVCS?

kraw ★★★★ ()
Ответ на: комментарий от anonymous

>Комара который кусает тебя за яйца надо убить быстро, а не ужасной смертью. Предавшего темного властелина раба, нужно мучать долго и изобретательно.

Умри, а лучше не скажешь!!! :D

kraw ★★★★ ()
Ответ на: комментарий от anonymous

>(1) Разработчик может свой бранч так же загружать на удалённый сервер, его изменения никому не помешают, потому что это отдельный бранч.

(2) Разработчик может иметь свой репозиторий на сервере, который регулярно синхронизируется с его локальным репозиторием.

Может. Но для этого его нужно специально заставить это делать и постоянно контроллировать. А если таких разработчиков много? А если они недисциплинированы?

В svn такая проблема не возникает вообще.

kraw ★★★★ ()
Ответ на: комментарий от anonymous

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

Ну вот мы делаем мод к некоторой игре. Зачем нам ветки? Собрали версию, зафиксировали тэг и работаем дальше.

Модель разработки такая.

kraw ★★★★ ()
Ответ на: комментарий от anonymous

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

Есть необходимость. Например при разработке тех же игр. Там куча таких объектов. Причем эти объекты должны быть доступны разработчикам по мере их написания. И контроль версий по ним тоже нужен и в привязке к программному коду.

kraw ★★★★ ()
Ответ на: комментарий от kraw

> Может. Но для этого его нужно специально заставить это делать и постоянно контроллировать. Уже писал выше. В случае с svn то же самое, пользователь может неделями ничего не комитить и разницы никакой с DVCS тут нет.

А если таких разработчиков много? А если они недисциплинированы?

Таких надо гнать в шею. DVCS не для быдла.

anonymous ()
Ответ на: комментарий от kraw

Теги в svn тоже корявые. Собственно в svn вообще нет честных тегов. Есть эмуляция тегов через копирование папок. С другой стороны в hg / git теги правильные — правильный тег это это просто имя для определённой ревизии.

anonymous ()
Ответ на: комментарий от debian6

> Пошёл учить mercurial. Но если что не так, знай, что она тебе прибъёт.

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

tailgunner ★★★★★ ()
Ответ на: комментарий от kraw

> Есть необходимость. Например при разработке тех же игр. Там куча таких объектов. Причем эти объекты должны быть доступны разработчикам по мере их написания.

При разработке движка разработчикам нужен доступ разве что к заглушкам ресурсов. Редактировать сами они их не будут.

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

Повторюсь, ты скорей всего никакой DVCS никогда не использовал. Потому что никто с DVCS на SVN обратно не бежит. Обратная ситуация происходит регулярно.

И контроль версий по ним тоже нужен и в привязке к программному коду.

Зачем? Это не решит никаких проблем.

anonymous ()
Ответ на: комментарий от kraw

> Я, например, регулярно делаю svnsync на домашний комп. Когда хостинг повалился, я просто это зеркало скопировал на другой хост. И тут же началась работа уже с ним.

Ну то есть ты используешь SVN в режиме DVCS? Прикольно. А как вы потом сливали изменения из зеркала в основную копию у провайдера?

И причем тут пункты: «бэкап» и «сбор статистики» (первое всё равно надо делать для машин пользователей, для второго существуют центральные репозитории)

Притом, что в случае svn это делается гораздо проще и дешевле.

То есть ты пробовал делать это в случае, например, Mercurial? И какие же сложности по сравнению с SVN?

Ну вот мы делаем мод к некоторой игре. Зачем нам ветки?

Я не знаю, как делаются моды. Но я знаю, как разрабатывается софт, и знаю, что такое «update before commit».

tailgunner ★★★★★ ()
Ответ на: комментарий от anonymous

> Может. Но для этого его нужно специально заставить это делать и постоянно контроллировать. Уже писал выше. В случае с svn то же самое, пользователь может неделями ничего не комитить и разницы никакой с DVCS тут нет.

Разница есть. Одно дело вообще не коммитить, другое дело, не синхронизировать репозитории.

А если таких разработчиков много? А если они недисциплинированы? Таких надо гнать в шею. DVCS не для быдла.

А я-то думал, что разработчику нужно уметь программировать. Как я былъ слепъ!!!

kraw ★★★★ ()
Ответ на: комментарий от anonymous

>Теги в svn тоже корявые. Собственно в svn вообще нет честных тегов. Есть эмуляция тегов через копирование папок. С другой стороны в hg / git теги правильные — правильный тег это это просто имя для определённой ревизии.

Но свою задачу они выполняют прекрасно. Вам шашечки или ехать?

kraw ★★★★ ()
Ответ на: комментарий от anonymous

>При разработке движка разработчикам нужен доступ разве что к заглушкам ресурсов. Редактировать сами они их не будут.

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

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

В чем состоит мучение? В том, что не нужно каждому админить локальный репозиторий?

Повторюсь, ты скорей всего никакой DVCS никогда не использовал. Потому что никто с DVCS на SVN обратно не бежит. Обратная ситуация происходит регулярно.

Сильный аргумент. «Крутые пацаны испоьзуют тока git!»

Зачем? Это не решит никаких проблем.

Что ты говоришь? Это решает проблему использования актуальных версий ресурсов.

kraw ★★★★ ()
Ответ на: комментарий от tailgunner

>Ну то есть ты используешь SVN в режиме DVCS? Прикольно. А как вы потом сливали изменения из зеркала в основную копию у провайдера?

Нет. Никак не сливали. Зеркало нужно в качестве аварийного зеркала. Текущая работа на нем не ведется. Только синхронизация. Просто оно реально спасло, когда хост навернулся и пропали несколько ревизий. Я просто полностью перенес репозиторий с зеркала на хост.

kraw ★★★★ ()
Ответ на: комментарий от kraw

>> А как вы потом сливали изменения из зеркала в основную копию у провайдера?

Нет. Никак не сливали. Зеркало нужно в качестве аварийного зеркала.

То есть твое сообщение сводится к «бэкапы рулят» или к «svnsync можно использовать для бэкапа»? Они воистену рулят; да, можно.

tailgunner ★★★★★ ()
Ответ на: комментарий от kraw

> Разница есть. Одно дело вообще не коммитить, другое дело, не синхронизировать репозитории.

Разница в одной команде. Если для тебя hg push myrepo / git push myrepo — это большая трудность, сложно представить как ты чистишь зубы.

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

Разработчику нужно уметь использовать инструменты разработки.

anonymous ()
Ответ на: комментарий от kraw

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

Отмазы в твоих постах. Я сказал всего лишь, что разработчикам кода лучше подходит DVCS.

В чем состоит мучение? В том, что не нужно каждому админить локальный репозиторий?

Мучение в работе без фич, которые есть в DVCS и попользовавшись которыми переходить обратно на SVN никак не хочется. «Администрирование» локального репозитория не сложнее «администрирования» рабочей копии svn.

Сильный аргумент.

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

Что ты говоришь? Это решает проблему использования актуальных версий ресурсов.

Я написал выше, для бинарей - svn, для текста - dvcs. Если разработчикам нужны актуальные ресурсы - svn update. Если дизайнерам нужен актуальный код (они всё равно его не смогу скомпилить, лол) - hg fetch / git pull

anonymous ()

Конкретные недостатки в mercurial:

- корявый rename: когда нужно было передвинуть директорию с тестами (около 5000) внутри репозитория, то в .hg получилось на 5000 файлов больше и размер .hg почти удвоился.

- невозможно работать только с частью репозитория (например, только с кодом без тестов), а subrepos пока неюзабельны, т.к. большая часть комманд и GUI/plugins их просто не поддерживают.

kamre ★★★ ()
Ответ на: комментарий от anonymous

>Разработчику нужно уметь использовать инструменты разработки.

Любые существующие, или которые нужны для решения его задачи?

kraw ★★★★ ()
Ответ на: комментарий от anonymous

>Я сказал всего лишь, что разработчикам кода лучше подходит DVCS.

А я утверждаю, что лучше подходит не во всех случаях. Описал случай, в котором прекрасно работает svn.

Мучение в работе без фич, которые есть в DVCS и попользовавшись которыми переходить обратно на SVN никак не хочется. «Администрирование» локального репозитория не сложнее «администрирования» рабочей копии svn.

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

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

Неочевидный. «Ты научись курить, потом бросить не сможешь» звучит малоубедитольно. Пока мне не удалось здесь прочесть ни одного довода кроме «это круто».

Я написал выше, для бинарей - svn, для текста - dvcs. Если разработчикам нужны актуальные ресурсы - svn update. Если дизайнерам нужен актуальный код (они всё равно его не смогу скомпилить, лол) - hg fetch / git pull

Т. е. держать 2 разнотипных репозитория вместо одного, при этом возникает проблема согласованности ревизий между двумя репозиториями.

kraw ★★★★ ()
Ответ на: комментарий от kraw

> Опишите мне, наконец, в чем состоят мои мучения (как администратора репозитория проекта)

С этого и надо было начинать...

и мучения простого разработчика.

Отсутствие локального коммита.

Бранчи нам делать не надо. Мержить не надо.

Участь художников не интересует.

tailgunner ★★★★★ ()
Ответ на: комментарий от kraw

> Какие фичи мне еще нужны? Может они настолько хороши, что следующий проект буду затевать с git.

http://whygitisbetterthanx.com/

Неочевидный. «Ты научись курить, потом бросить не сможешь» звучит малоубедитольно.

В данном случае «курение» не вредит здоровью, поэтому «не читал, но осуждаю» подходит лучше. Ты не использовал DVCS, поэтому спор с тобой бессмысленный.

anonymous ()
Ответ на: комментарий от tailgunner

>Отсутствие локального коммита.

Для чего он нам нужен?

Участь художников не интересует.

Вообще-то программисты.

kraw ★★★★ ()
Ответ на: комментарий от anonymous

>Ты не использовал DVCS, поэтому спор с тобой бессмысленный.

Когда кто-то не может сформулировать преимущества продукта, это означает, что он сам их не понимает.

kraw ★★★★ ()
Ответ на: комментарий от anonymous

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

я за преимущество слова «круто» и «для небылдла» не считаю

(1) Скорость (в первую очередь из-за локальности большинства операций)

тут можно поспорить, имея гигабитную сеть (и нормальную сетевую инфраструктуру) и на том конце даже чуть выше чем entry-level сервак со сказёвыми дисками в raid0 (точнее 10 или 50) ты получишь просадку по скорости коммита по сравнению с svn (начальство не очень любит, как правило, мощные тачки ставить разработчикам), я это гарантирую тебе

но вообще тут всё зависит от того что лежит в репах

так что по данному пункту неубедительно

(2) Эффективный бранч/мерж с наглядной историей

тут спорить глупо, согласен

(3) Возможность использовать разные рабочие процессы в зависимости от нужд проекта: http://progit.org/book/ch5-1.html

не пойму почему это нельзя делать с svn, /dev/hands invalid?

(4) Различные маленькие удобности такие как git stash / hg shelve, stgit / mercurial queues, описывать долго, можешь сам нагуглить.

синтаксический сахер

ну и результат - кроме бранчей (и то условно) особых преимуществ Вы не назвали

shty ★★★★★ ()
Ответ на: комментарий от anonymous

> есть такая подобласть «разработки ПО» как «разработка игрового ПО» (к примеру)

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

ну да, ну да, конечно не интересны, а тестируют написанное оне вытягивая перст в воздух :)

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

shty ★★★★★ ()
Ответ на: комментарий от anonymous

Комара который кусает тебя за яйца надо убить быстро, а не ужасной смертью.

может всё же лучше устранить первопричину и не ходить с голыми яйцами?

shty ★★★★★ ()
Ответ на: комментарий от anonymous

> А если таких разработчиков много? А если они недисциплинированы?

Таких надо гнать в шею. DVCS не для быдла.

охохо, «ылита понабижала» :) Вы работали хоть раз на должности PM?

shty ★★★★★ ()
Ответ на: комментарий от anonymous

Не вижу смысла мучать девелоперов кривым svn-ом при разработке кода

ты так и не сказал почему он кривой :)

Потому что никто с DVCS на SVN обратно не бежит.

вменяемые люди не «бегают», а выбирают средства исходя из задачи

shty ★★★★★ ()
Ответ на: комментарий от anonymous

> А я-то думал, что разработчику нужно уметь программировать.

Разработчику нужно уметь использовать инструменты разработки.

разработчику нужно писать код и фиксить баги, а не заниматься х..нёй, ему не за нёе деньги платят, странно что до Вас это никак не доходит

shty ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.