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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

обоснуй

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Даже команда для создания тега в svn выглядит уродливо. Зачем-то нужно указывать URL

Сравни сам:

svn: http://svnbook.red-bean.com/en/1.1/ch04s06.html

hg: http://mercurial.selenic.com/wiki/Tag

git: http://progit.org/book/ch2-10.html

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

http://whygitisbetterthanx.com/

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

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

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

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

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

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

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

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

Я кинул тебе ссылку и выше писал своими словами. Прочитай внимательнее.

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

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

(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, описывать долго, можешь сам нагуглить.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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