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

Если дизайнерам нужен актуальный код (они всё равно его не смогу скомпилить, лол) - hg fetch / git pull

гейм-дизайнерам нужны актуальные скрипты, которые подхватит скомпилированный сервер/клиент/whatever и нужно иметь возможность их менять, и они это делают, и часто

> ты получишь просадку по скорости коммита по сравнению с svn (начальство не очень любит, как правило, мощные тачки ставить разработчикам), я это гарантирую тебе

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

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

Потому что всё придётся делать руками и это будет занимать много времени. Как например реализовать code review, так чтобы только reviewer мог коммитить в основной репо? слать diffы по почте не предлагать.

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

Why not? Если что-то можно автоматизировать, почему бы это не автоматизировать? Плюс я бы посмотрел на то как ты с svn-ом будешь эмулировать mercurial queues

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

Ага, особенно когда надо исправить баг в 3-х стабильных ветках svn очень помогает, дооо

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

Задач для которых подходит svn не много, если нет больших бинарей, DVCS будет эффективнее ибо см. выше.

Скрипты — это код. Любой человек, способный писать код, способен освоить git / hg.

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

Ужас, сколько пафоса.

> ты получишь просадку по скорости коммита по сравнению с svn (начальство не очень любит, как правило, мощные тачки ставить разработчикам), я это гарантирую тебе

пруфлинк на бенчмарки.

нету, это из опыта работы

По моему опыту, на более менее крупных проектах svn тормозит вне зависимости от железа.

это на каких же (приложите описание плиз)?

С другой стороны локальный коммит очень быстр и не сломается из-за того, что кто-то коммитнул быстрее тебя.

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

Как например реализовать code review, так чтобы только reviewer мог коммитить в основной репо? слать diffы по почте не предлагать.

а в чём проблема? в svn это делается куда проще чем во всех обсуждаемых системах вместе взятых, ставишь read only для everyone на trunk, разрешаешь доступ кому надо и voi'la

Плюс я бы посмотрел на то как ты с svn-ом будешь эмулировать mercurial queues

Ваша проблема в том что Вы всё рассматриваете проблему с точки зрения эмуляции работы mercurial svn'ом - это в корне порочный подход

поймите же наконец, svn - это сравнимая по мощности система контроля версий, да, у неё есть ряд недостатков перед mercurial, но и последний не безрешен и где-то удобнее применять первую vcs, а где-то вторую

это как научился кто-то работать по методологии agile и давай применять её ко всем проектам подряд, а для больших и распределённых команд она даёт не самый лучший результат или, к примеру, знает супер архитектор RUP и давай его в команде из 3 человек человек насаждать - и то и то фигня полная, в выборе инструмента надо идти от задачи и от условий решения этой задачи

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

Ага, особенно когда надо исправить баг в 3-х стабильных ветках svn очень помогает, дооо

мсье не умеет накатывать патчи? :)

Скрипты — это код. Любой человек, способный писать код, способен освоить git / hg.

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

и да

Скрипты — это код. Любой человек, способный писать код способен написать с нуля ядро linux за 3 дня.

//fixed

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

Своими словами ты только посоветовал держать 2 отдельных репозитория для разных видов ресурсов.

А ссылки я тоже умею давать. Например http://google.com - той же ценности ссылка для обсуждаемого вопроса.

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

А в бане, туалете, во время соития с возлюбленной ты все проделываешь не снимая штанов?

> Скрипты — это код. Любой человек, способный писать код, способен освоить git / hg.

Правильно так: Любой человек способен освоить hg.

Про git не скажу, что его любой освоит. А вот hg вообще без проблем.

>Ага, особенно когда надо исправить баг в 3-х стабильных ветках svn очень помогает, дооо

1. Как я говорил выше, мой пример не предполагает использования веток.

2. svn и в этом случае помогает.

>Любой человек, способный писать код, способен освоить git / hg.

Лобой человек может освоить замену сцепления в автомобиле. Но большинство предпочитает этого не делать.

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

Ужас, сколько пафоса.

«Художников много, а главначпупс один» В. В. Маяковский «Баня»

> это на каких же (приложите описание плиз)?

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

если по каким-либо причинам это невозможно, то делается бранч и кто это в твой бранч коммитить будет? :))

Для бранчей рулит DVCS, ты сам признал.

а в чём проблема? в svn это делается куда проще чем во всех обсуждаемых системах вместе взятых, ставишь read only для everyone на trunk, разрешаешь доступ кому надо и voi'la

Каким образом патчи будут передаваться от разработчика к ревьюверу? Уж не diff-ы ли по почте?

Ваша проблема в том что Вы всё рассматриваете проблему с точки зрения эмуляции работы mercurial svn'ом - это в корне порочный подход

Ты сказал, что это синтаксический сахар, Прошу описания как ты синтаксический сахар в виде mercurial queues будешь реализовывать в svn. Если никак, то значит это уже не синтаксический сахар - а самостоятельная фича. К тому же местами очень полезная. Я прекрасно знаю как работать с svn и использовал его несколько лет, опять же из своего опыта могу сказать, что с mercurial-ом работать приятнее.

Поймите же наконец, svn - это сравнимая по мощности система контроля версий

Это система предыдущего поколения, которая идеологически стоит на шаг два позади. Пойми уже наконец, что distributed vcs - это функциональное надмножество centralized vcs. Поэтому сравнение что лучше имеет очевидный результат.

да, у неё есть ряд недостатков перед mercurial, но и последний не безрешен и где-то удобнее применять первую vcs, а где-то вторую

Скажем так количество недостатков svn сильно больше недостатков hg. В этом треде примеры уже были.

> мсье не умеет накатывать патчи? :)

Зачем делать руками то, что можно автоматизировать?

> да-да, а потом освоить ещё что-нибудь и ещё, может всё таки человек работать будет, а не осваивать кучу хренотени непойми зачем ему нужную? :)

Аргумент из серии: нет времени точить пилу — нужно пилить © Нужно один раз освоить годный инструмент и потом получать профит.

> Своими словами ты только посоветовал держать 2 отдельных репозитория для разных видов ресурсов.

Ты либо слепой, либо тупой.

Раз: http://www.linux.org.ru/jump-message.jsp?msgid=5454685&cid=5460566

Два: http://www.linux.org.ru/jump-message.jsp?msgid=5454685&cid=5464061

Если ты не хочешь или не можешь читать, покинь эту дискуссию.

> Лобой человек может освоить замену сцепления в автомобиле. Но большинство предпочитает этого не делать.

Детектирую butt hurt. Если ты не осилил DVCS, это не означает, что никто не осилил. Может быть проблема в тебе?

>Ты либо слепой, либо тупой.

Раз: http://www.linux.org.ru/jump-message.jsp?msgid=5454685&cid=5460566

Два: http://www.linux.org.ru/jump-message.jsp?msgid=5454685&cid=5464061

Если ты не хочешь или не можешь читать, покинь эту дискуссию.

Своими словами можешь хоть что-то сформулировать?

Я тебе 100 раз написал, что в моем случае бранчи не нужны, а ты все убеждаешь, что бранчить svn неудобно. Так, что насчет тупости «врачу - исцелися сам»

>Если ты не осилил DVCS, это не означает, что никто не осилил. Может быть проблема в тебе?

Еще раз спрошу - для чего мне в моем случае нужен DVCS, если обычным svn мои задачи решаются быстрее, эффективнее, проще и дешевле?

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

Причем этьи разработчики сделали продукт, который еще на альфа версии завоевал большую популярность у целевой аудитории.

Теперь еще раз, ради чего, я должен завести DVCS, заставить этих разработчиков его освоить, постоянно админить свои локальные репозитории, следить за своевременной синхронизацией? Вместо того, чтобы работать с единым репозиторием, не грузить их проблемами администрирования и всего лишь позсказать 3 команды: checkout, update и commit, которые они даже не в консоли набирают, а вызывают «кликом мышки». Что я от этого выиграю?

> Своими словами можешь хоть что-то сформулировать?

Я тебе привёл ссылку на пост в этом треде, где я своими словами сформулировал преимущества. Ферштейн?

Я тебе 100 раз написал, что в моем случае бранчи не нужны, а ты все убеждаешь, что бранчить svn неудобно.

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

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

Ужас, сколько пафоса.

У тебя какие-то странные галлюцинации. С чего бы мне интересоваться участью художников?

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

Ужас, сколько пафоса.

«Художников много, а главначпупс один» В. В. Маяковский «Баня»

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

Да не причём. Просто сначала заявляется, что svn не нужен, что hg решит все проблемы. А потом оказывается, если прочитать про hg, то один хранит данные по rsync, другой в svn, и по их словам, это единственно правильно и единственно удобно, подстраиваться под систему только потому, что система это круто. Я такое раньше только среди писак на дельфи и визуалстудио встречал. Зато каждый твердит про ветки, которые многим просто совершенно не нужны, а кому нужны, то многим из них и вариант из svn подходит. Но нет же, художники не нужны, svn не нужен, данные не нужны, нужен только hg, потому что это круто. Программизм головного мозга, кажется, так это принято тут величать?

В SVN централизация, за каждый момент отвечает чётко кто-то, с именем и фамилией (если он не индус). А в dvcs анархия, каждый может себе в уголочке что-то править сам по себе, как ему хочется, а потом всё это сливается воедино и остаётся только надеяться на чудо-мержилку.

> Там, где я работаю, художников вообще нет, зато много прогеров

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

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

Спасибо, долго смеялся. Можно узнать, каким образом нужно «админить» локальный репозиторий git? А то я сколько работал с ним, но об «администрировании» слышу впервые. Может, что-то важное упустил?

всего лишь позсказать 3 команды: checkout, update и commit, которые они даже не в консоли набирают, а вызывают «кликом мышки».

[irony] Похоже, у Вас очень профессиональные разработчики! [/irony] Три базовых команды svn, и те надо подсказывать. И вдобавок страдают консолефобией (и даже хоткеев IDE для работы с VCS не знают).

Я сам разработчик. После того, как освоил git, заметил, насколько удобнее и проще стало работать по сравнению с svn. Конечно, 3 командами тут не обойтись, но в остальных аспектах DVCS делают VCS как детей.

google gitflow, что тут ещё сказать

>> Там, где я работаю, художников вообще нет, зато много прогеров

Работает трактор, люди творят.

Гыгы, сколько пафоса.

> Еще раз спрошу - для чего мне в моем случае нужен DVCS, если обычным svn мои задачи решаются быстрее, эффективнее, проще и дешевле?

Быстрые локальные операции - commit, log, annotate Простые и понятные теги.

Мне нужно не «осилить DVCS», а решить конкретную задачу.

DVCS нужен, чтобы решать задачу эффективнее.

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

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

постоянно админить свои локальные репозитории

Ололо, рабочую копию ты не устаёшь одминить?

и всего лишь позсказать 3 команды: checkout, update и commit

Чем это отличается от clone, pull, commit, push? На одну команду больше? Да, действительно, зачем мучать мозг удержанием целых 4-х команд! Что это вообще за разработчики, которые version control не знают? Профессионалы высокого уровня говоришь?

которые они даже не в консоли набирают, а вызывают «кликом мышки»

http://tortoisehg.bitbucket.org/

У меня был хороший тренер по пафосу. Жаль, быстро кончился.

> В SVN централизация, за каждый момент отвечает чётко кто-то, с именем и фамилией (если он не индус).

Ага, обычно это означает использование одного репозитория-помойки для всех проектов. Очень распространённый ынтерпрайз паттерн. Ненуачо, всё централизовано в одной помойке!

А в dvcs анархия, каждый может себе в уголочке что-то править сам по себе, как ему хочется, а потом всё это сливается воедино и остаётся только надеяться на чудо-мержилку.

Интересно, как твой дебиан работает, если при разработке линукс ядра DVCS анархия? Чуть-мержилка воистину творит чудеса!

>[irony] Похоже, у Вас очень профессиональные разработчики! [/irony] Три базовых команды svn, и те надо подсказывать. И вдобавок страдают консолефобией (и даже хоткеев IDE для работы с VCS не знают).

Я Вам больше скажу, про систему контроля версий они впервые от меня узнали. До того все изменения собирали и рассылали вручную. Зато они хорошо умеют писать скрипты для игры. И пишут настолько эффективный код, что реализуют такие фичи, которые разработчикам оригинальной игры и в голову не приходили. При этом исправили многие ошибки оригинальной игры. Это и есть профессионализм.

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

> А потом оказывается, если прочитать про hg, то один хранит данные по rsync, другой в svn, и по их словам, это единственно правильно и единственно удобно

О ЛММ, что такое ты читаешь? Про большие двоичные файлы? А про разработку _софта_, а не медиа, тебе есть что сказать?

> У меня был хороший тренер по пафосу.

У тебя были хорошие глюки.

Жаль, быстро кончился.

Ты, конечно, понимаешь, как решить эту проблему %)

>DVCS нужен, чтобы решать задачу эффективнее.

За счет чего эта эффективность повысится? Не в неком абстрактном проекте с ветвями, а в моем конкретном проекте.

Очень может быть, что они уже использовали DVCS

Не использовали. Даже о VCS узнали от меня.

Профессионалы высокого уровня говоришь?

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

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

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

А что за игра-то хоть? Не срача ради, просто интересно

> Я Вам больше скажу, про систему контроля версий они впервые от меня узнали.

Можно, конечно, наменить их на тех, кто любит вести локальные репозитории

ROTFL. Ты и правда считаешь, что люди, достаточно дисциплинированные для работы без VCS вообше, не осилят hg и будут забывать вовремя сливать изменения в центральный репозиторий? %)

>Ага, обычно это означает использование одного репозитория-помойки для всех проектов. Очень распространённый ынтерпрайз паттерн. Ненуачо, всё централизовано в одной помойке!

Зачем? Для каждого проекта свой репозиторий.

Интересно, как твой дебиан работает, если при разработке линукс ядра DVCS анархия? Чуть-мержилка воистину творит чудеса!

А вот в ядре, как раз, требуется ведение отдельных веток. И решение отдельных задач с большой степенью автономности. В одной ветке делают драйвер некого устройства, в другой, переделывают механизм управления памятью, в третьей только исправляют ошибки стабильной версии и т. д. Своя специфика. В этом случае лучше подходит DVCS. Но у меня-то совсем другой случай. В моем случае больше подходит единый репозиторий.

>А про разработку _софта_, а не медиа, тебе есть что сказать?

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

PS: «Игры не нужны» - не предлагать!

> За счет чего эта эффективность повысится? Не в неком абстрактном проекте с ветвями, а в моем конкретном проекте.

Это написано в том посте, на который ты отвечал. Мотай страницу вверх пока не найдёшь или палец не устанет.

Причём тут разработка софта, или документов, или ещё чего-то? Заявление было «svn не нужен!!!». Я так тоже могу возразить, что Мерседес не нужен, я на нём не езжу, предпочитаю свой скромный Бентли. А как на деле вышло, то hg нужен только для толпы обормотов, которые не могут самоорганизовываться, но согласны на все налагаемые hg ограничения, им приходится задумываться по многим поводам.

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

>О да, конечно! Если человек использует git, то он ни за что не сможет написать хороший скрипт для игры. Блестящий логический вывод, просто блестящий )))

Такое тоже встречается.

А что за игра-то хоть? Не срача ради, просто интересно

Мод к «Готике». «Народ Миненталя». Полностью некоммерческий проект. Впрочем, лицензия иного и не позволяет.

Начат еще один мод, но там пока «вилами на воде писано».

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

>Ты и правда считаешь, что люди, достаточно дисциплинированные для работы без VCS вообше, не осилят hg и будут забывать вовремя сливать изменения в центральный репозиторий?

Осилить-то осилят. Но:

1) Захотят ли осилить

2) Что это даст? (в моем случае)

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

> 1) Захотят ли осилить

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

2) Что это даст? (в моем случае)

...и даст ли хоть что-нибудь. Я не знаю - никогда не работал с художниками.

> Причём тут разработка софта, или документов, или ещё чего-то?

Вверху по ветке сказано, чем плох hg при работе с «еще чем» (большими двоичными файлам). Насчет «документов» - хз, я не разрабатываю «документы». Полагаю, там тупо пофиг, какая VCS, потому что ни diff, ни merge не имеют особого смысла.

Заявление было «svn не нужен!!!»

Скорее «svn убог». И да, оба заявления следует рассмартирвать в контексте названия топика. Потому что иначе можно дойти до доводов, что SVN нужен разработчикам самого SVN (им за это деньги платят).

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

Я полностью согласен с текстом, хотя и думаю, что ты опечатался («hg» вместо «svn»).

>>А про разработку _софта_, а не медиа, тебе есть что сказать?

А то, что в разрабатываемом софте может присутствовать и медиа, тебе в голову не приходит?

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

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

А в бане, туалете, во время соития с возлюбленной ты все проделываешь не снимая штанов?

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

> это на каких же (приложите описание плиз)?

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

так в чём Вы видите преимущества в использовании dvcs при решении данной задаче

> если по каким-либо причинам это невозможно, то делается бранч и кто это в твой бранч коммитить будет? :))

Для бранчей рулит DVCS, ты сам признал.

не-не-не, рулит для merge :) бранчинг и в svn ничё так, хотя и тупо копирование

> а в чём проблема? в svn это делается куда проще чем во всех обсуждаемых системах вместе взятых, ставишь read only для everyone на trunk, разрешаешь доступ кому надо и voi'la

Каким образом патчи будут передаваться от разработчика к ревьюверу? Уж не diff-ы ли по почте?

а кто мешает завести отдельный бранч или репозитарий?