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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

и да

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

//fixed

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Название не имеет смысла, коробочный продукт для разработчиков. Размер ~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. В этом треде примеры уже были.

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

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

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

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

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

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

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

> Своими словами ты только посоветовал держать 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

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

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

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

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

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

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

Раз: 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 неудобно. Так, что насчет тупости «врачу - исцелися сам»

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

http://tortoisehg.bitbucket.org/

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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