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 ()

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

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

Разработка компьютерной игры не софтверный проект?

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

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

Разработка компьютерной игры не софтверный проект?

Определи понятие «разработка компьютерной игры».

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

>Определи понятие «разработка компьютерной игры».

А понятия «компьютерная игра», «разработка», «куомпьютер», «игра» определять не нужно? Чего уж мелочиться?

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

>> Определи понятие «разработка компьютерной игры».

А понятия «компьютерная игра», «разработка», «куомпьютер», «игра» определять не нужно?

Если тебе нетрудно, определи и «разработку».

Чего уж мелочиться?

Не мелочись.

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

>Если тебе нетрудно, определи и «разработку».

Все ясно. Аргументов нет, начинаем петросянить.

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

> Не мелочись.

Авраам родил Исаака; Исаак родил Иакова; Иаков родил Иуду и братьев его; Иуда родил Фареса и Зару от Фамари; Фарес родил Есрома; Есром родил Арама; Арам родил Аминадава; Аминадав родил Наассона; Наассон родил Салмона; Салмон родил Вооза от Рахавы; Вооз родил Овида от Руфи; Овид родил Иессея; Иессей родил Давида царя; Давид царь родил Соломона от бывшей за Уриею; Соломон родил Ровоама; Ровоам родил Авию; Авия родил Асу; Аса родил Иосафата; Иосафат родил Иорама; Иорам родил Озию; Озия родил Иоафама; Иоафам родил Ахаза; Ахаз родил Езекию; Езекия родил Манассию; Манассия родил Амона; Амон родил Иосию; Иосия родил Иоакима; Иоаким родил Иехонию и братьев его, перед переселением в Вавилон. По переселении же в Вавилон, Иехония родил Салафииля; Салафииль родил Зоровавеля; Зоровавель родил Авиуда; Авиуд родил Елиакима; Елиаким родил Азора; Азор родил Садока; Садок родил Ахима; Ахим родил Елиуда; Елиуд родил Елеазара; Елеазар родил Матфана; Матфан родил Иакова; Иаков родил Иосифа, мужа Марии, от Которой родился Иисус, называемый Христос.

Мф 1:2-16

Дальше продолжать?

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

>>> Определи понятие «разработка компьютерной игры».

А понятия «компьютерная игра», «разработка», «куомпьютер», «игра» определять не нужно?

Если тебе нетрудно, определи и «разработку».

Все ясно. Аргументов нет, начинаем петросянить.

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

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

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

Ты сказал, что это синтаксический сахар, Прошу описания как ты синтаксический сахар в виде mercurial queues будешь реализовывать в svn.

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

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

синтаксический сахар в чистом виде, оба инструмента решают задачу и решают хорошо, то что это делать приятнее (ну пусть так, хотя я бы добавил слова «местами» и «порой») с использованием mercurial и есть пресловутый сахар

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

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

Это система предыдущего поколения, которая идеологически стоит на шаг два позади.

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

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

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

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

«руками» - это когда тупо руками, сделать же патч и применить его к нужным веткам - дело пары команд

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

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

Аргумент из серии: нет времени точить пилу — нужно пилить

именно так, не согласны?

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

все здесь обсуждаемые инструменты являются «годными», обратное никем пока не показано

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

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

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

хехе, знаменитый юношеский максимализм :)

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

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

ололо, Вы видели внутренности хотя бы захудалой ММО игры? :)

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

Кстати, я не хотел обидеть индусов. Просто у них вроде фамилий нет :)

debian6 ()

для упёртых джедаев

Choosing a revision control tool

With the exception of CVS, all of the tools listed above have unique strengths that suit them to particular styles of work. There is no single revision control tool that is best in all situations.

As an example, Subversion is a good choice for working with frequently edited binary files, due to its centralised nature and support for file locking.

I personally find Mercurial's properties of simplicity, performance, and good merge support to be a compelling combination that has served me well for several years.

взято отсюда

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

Кстати, я не хотел обидеть индусов. Просто у них вроде фамилий нет :)

ну я не про индусов :) я про то что subversion позволяет использовать более одного репозитария одновременно если есть такая необходимость

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

>Я никогда не разрабатывал компьютерных игр и не знаю, как это происходит

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

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

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

иногда надо делать git fsck и git repack

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

> Теперь еще раз, ради чего, я должен завести DVCS, заставить этих разработчиков его освоить, постоянно админить свои локальные репозитории, следить за своевременной синхронизацией? Вместо того, чтобы работать с единым репозиторием,

Что я от этого выиграю?


1. Более эффективное хранение бинарных файлов, обновление rsync-ом
2. git rebase, git cherrypick — более эффективное слияние/объединение
3. git bisect, git bisect good / git bisect bad — бинарный поиск регрессий
4. Не совсем git/hg, более workflow: посмотри к примеру, типичный workflow на github-е. Кто-то делает репозиторий, другие клонируют, пишут *и тестируют* патчи в своей локальной ветке, потом pull request для сливания фич, готового работающего кода. Например, браузеры uzbl, luakit — разрабатываются сливанием нескольких форков с наиболее вкусными фичами
5. Prophet, SD (SimpleDeffects), RT (RequestTracker). Distributed issue tracker как жанр в виде Prophet , SD и/или других distributed bug tracker.
6. ikiwiki, jekyl и т.п. — wiki в git. Из неё просто генерируются сайты/блоги. Это не совсем чтобы mvn site, но по удобству похоже (после затачивания под себя шаблонов и т.п.)

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

> Например, браузеры uzbl, luakit — разрабатываются сливанием нескольких форков с наиболее вкусными фичами

вот так к примеру, организован процесс:
http://github.com/Dieterbe/uzbl/network http://github.com/blog/39-say-hello-to-the-network-graph-visualizer

в основную ветку сливается код от «лейтенантов», остальные заинтересованные делают watch на нужную ветку и сливают изменения с неё в свой форк вручную

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

>иногда надо делать git fsck и git repack

А синхронизировать с другими репозиториями?

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

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

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


за счёт того, что «интегратору» ака мейнтейнеру основной ветки не нужно мёржить изменения вручную — это за него сделают лейтенанты. Лейтенант в своей ветке делает фичу, потом вручную сливает изменения с mainline, потом шлёт pull request. Интегратор затем просто накладывает его изменения, а если не накладываются — пинает лейтенанта, пока он не приведёт свой форк в соответствие. Итого, мейнтейнер основной ветки разгружается от ручной работы, и начинает мыслить проект на уровне работающих, протестированных лейтенантами фич.

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

git push/ git pull по запросу, в соответствии с выбранным workflow.

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

>1. Более эффективное хранение бинарных файлов, обновление rsync-ом

В чем выражается эффективность? В объеме, времени доступа? Какова величина выигрыша? Стоит ли ради нее мигрировать? Перевесит ли она большую сложность?

2. git rebase, git cherrypick — более эффективное слияние/объединение

Это не наш случай. У нас нет ветвей. Модель разработки их не требует.

3. git bisect, git bisect good / git bisect bad — бинарный поиск регрессий

Тоже не наш случай. Не возникало такой необходимости.

4. Не совсем git/hg, более workflow: посмотри к примеру, типичный workflow на github-е. Кто-то делает репозиторий, другие клонируют, пишут *и тестируют* патчи в своей локальной ветке, потом pull request для сливания фич, готового работающего кода. Например, браузеры uzbl, luakit — разрабатываются сливанием нескольких форков с наиболее вкусными фичами

Это опять про ветки. Не наш случай.

5. Prophet, SD (SimpleDeffects), RT (RequestTracker). Distributed issue tracker как жанр в виде Prophet , SD и/или других distributed bug tracker.

svn хорошо интегрирован с trac. Для наших целей вполне хватает.

6. ikiwiki, jekyl и т.п. — wiki в git. Из неё просто генерируются сайты/блоги. Это не совсем чтобы mvn site, но по удобству похоже (после затачивания под себя шаблонов и т.п.)

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

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

PPS: Опять жеп повторюсь. Я сравниваю DVCS и svn не вообще, а применительно к совершенно конкретному случаю. И вовсе не утверждаю, что «git не нужен». Я утверждаю, что «в данном случае, применение svn более оправдано». С учетом всех факторов.

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

>за счёт того, что «интегратору» ака мейнтейнеру основной ветки не нужно мёржить изменения вручную — это за него сделают лейтенанты. Лейтенант в своей ветке делает фичу, потом вручную сливает изменения с mainline, потом шлёт pull request. Интегратор затем просто накладывает его изменения, а если не накладываются — пинает лейтенанта, пока он не приведёт свой форк в соответствие. Итого, мейнтейнер основной ветки разгружается от ручной работы, и начинает мыслить проект на уровне работающих, протестированных лейтенантами фич.

Так в том-то и дело, что у нас нет форков, нет веток. Они в нашем случае не нужны вообще.

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

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

не совсем. К примеру, делаю я сайт. Делаю рыбу в PhotoShop/Illustrator (большие файлы), режу на куски в ImageReady, делаю вёрстку в DreamWeaver — mockup интерфейса, и пишу логику на чём-то вроде PHP. Затем, вёрстку переделываю по emacs+muse и одной командой M-x save-and-publish публикую из markdown/wiki разметки в html прямо на сайт.
Софтверная часть — CMS или что там на PHP + конфиг для публикации из muse. Остальное — прототип интерфейса или сам рабочий интерфейс, нормально свёрстанный в css.

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

а если что-то сломают в транке, как собираетесь разруливать? или есть какая-то политика «коммитить только оттестированный код»?

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

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

Вопрос в величине файлов и том, насколько хорошо они поддаются дельтификации. Потому что одно дело видеоролик на пол-гига, другое - битмап на 100 метров. И еще важен поток изменений - если 2/3 изменений делаются на медийных файлах, это уже не софтверный проект.

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

>а если что-то сломают в транке, как собираетесь разруливать? или есть какая-то политика «коммитить только оттестированный код»?

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

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

А так, если кто-то ломал свой кусок, это не влияло на других.

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

> У каждого был автономный код.

Рабочая копия SVN?

Ну и сборщик отслеживал изменения на соотвествие Регламенту.

Каким образом он получал изменения?

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

>> У каждого был автономный код.

Рабочая копия SVN?

Нет, конечно. Каждый работал со своим куском кода. Т. е. у каждого были свои файлы. Конечно, часть файлов правили совместно, но там коллизий не возникало. Это были правки наподобие «поместить новый объект в локацию» или «сменить расписание персонажа при переходе к такой-то главе». Т. е. при одновременной правке таких файлов все мержилось (svn update) без проблем.

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

... репозиторий был один. Единственное требование было - не поднимать некомпиллируемый код в репозиторий.

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

>>> У каждого был автономный код.

Рабочая копия SVN?

Нет, конечно.

Афигеть. Они как-то получали код, не обращаясь к SVN?

Единственное требование было - не поднимать некомпиллируемый код в репозиторий.

Как код проверялся на соотвествие Регламенту?

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

Увы, иногда эти «юноши» - твои работодатели. Печально, но факт.

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

>Афигеть. Они как-то получали код, не обращаясь к SVN?

Ты вообще читаешь, что я пишу?

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

Увы, иногда эти «юноши» - твои работодатели. Печально, но факт.

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

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

>> Афигеть. Они как-то получали код, не обращаясь к SVN?

Ты вообще читаешь, что я пишу?

Я - да, а ты?

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

> В чем выражается эффективность? В объеме, времени доступа? Какова величина выигрыша? Стоит ли ради нее мигрировать? Перевесит ли она большую сложность?

Мерять надо на своём репозитории. На разных других были примеры GIT раз в 10-5 компактнее (где-то видел сравнение для KDE: 45+ Gb в SVN, ~7-8 Gb в Git; Mozilla: 12 Gb SVN, 420 Mb git, но сейчас она на hg (ибо венда фоксова), интересно, сколько репозиторий весит?)

Это надо конвертировать свой репозиторий например через git-svn http://www.kernel.org/pub/software/scm/git/docs/git-svn.html так: (git svn clone для начала, потом получаем полноценный git репозиторий)
http://leonid.shevtsov.me/22-07-2009/perenos-svn-repozitariya-v-git/
http://utsl.gen.nz/talks/git-svn/intro.html#howto-fetch-slow

http://google-opensource.blogspot.com/2008/05/develop-with-git-on-google-code... http://pauldowman.com/2008/07/26/how-to-convert-from-subversion-to-git/ http://weblog.redlinesoftware.com/2008/2/24/converting-subversion-repositorie... или так http://packages.debian.org/ru/sid/svn-all-fast-export

можно просто работать с SVN через git : http://linsovet.com/git-svn-sync-changes http://flavio.castelli.name/howto_use_git_with_svn

: git svn fetch/... /git svn dcommit для push из git в SVN

Бинарные файлы жмёт по дельтам, по изменениям. git gc http://www.kernel.org/pub/software/scm/git/docs/git-gc.html , git repack http://www.kernel.org/pub/software/scm/git/docs/git-repack.html , заново перепакует репозиторий, что может сильно уменьшить его размер. Запускать надо в зависимости от активности репозиториев * размер изменяемых файлов, может ужать репозиторий в 2-3 раза.
В общем-то размер репозитория мало на что влияет, поскольку если уже был checkout, git checkout/git fetch будет качать только дельты. Разница будет заметна только если делается новый checkout через git clone.

Стоит или не стоит мигрировать  — нужно попробовать и оценить самому. Например, проекты Mozilla, KDE, OpenSolaris, ЕМНИП Qt и т.п. сами сначала написали скрипт для миграции/конвертирования репозитория, потом пощупали другую VCS «в работе», потом через какое-то время всем участникам проекта оказалось, что юзать новую DVCS удобнее, чем старую, и миграция, можно сказать, прошла гладко автоматически.

В твоём случае (мод к Готике1) хмм.. большая часть разрабов/тестеров скорее всего сидит под виндой, так что тут что hg, что git примерно одинаковый профит. git под винду в виде msysgit вполне юзабелен (но надо проверить что там с русским языком в коммитах и т.п., когда-то нужно было настраивать кодовую страницу и т.п.).
Сам юзаю hg+TortoiseHg с батарейками для поддержки сайта, под виндой оно не сложнее SVN. Msysgit примерно так же просто.

«БольшЕй сложности» я тут не вижу. Можно тупо использовать git как замену SVN: git svn fetch/git commit/git rebase/git amend/.../ git svn dcommit, при этом реализовав практически тот же workflow, что и в SVN.

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

Можно организовать другой workflow, вроде Линуса с лейтенантами, staged trees, и т.п. Например, напрашиваются 2 ветки: одна для feature branch, разрабатывать новые фичи, вторая для багфиксинга, а trunk только для сливания изменений из этих 1+n в основную.

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


вот, то есть feature branch или отдельная ветка для багфиксинга. Не очень оно усложняет процесс в git, можно сделать хоть 10500 веток на каждую отдельную фичу.
Берём trunk, клонируем: git checkout -b foobar, получаем новую ветку foobar и переключаемся в неё. Пишем код (скрипты, ресурсы, заметки в org-mode для емакса «типа design document», wiki на сайт, и т.п.). Тестируем. Когда всё работает ОК, переключаемся назад в trunk, сливаем туда изменения из ветки foobar git checkout master; git merge foobar, изменения обычно накладываются успешно (ибо ветка сделана клонированием), но кто-то мог внести в trunk патч, который будет конфликтовать, тогда ресолвим конфликты (через git merge -s , git rebase -i, или вручную), и делаем commit (который будет накладываться успешно). Можно и лучше делать наоборот: слить в foobar изменения из транка (master), проверить что всё накладывается ОК, и ресолвить конфликты в foobar, затем переключиться в транк и слить изменения туда из foobar).
Потом имеем: ветку master (транк), с подгруженной фичей, которая протестирована и работает, и «замороженную» ветку foobar (которая не изменялась после этой фичи).

В итоге, процесс разработки состоит из:
1. создали feature branch, протестировали, обновили её из trunk
2. слили в trunk из feature branch
3. ветку feature branch можно выкинуть (удалить) (или оставить в назидание потомкам, для доработки фичи в будущем).

Всякие логически левые коммиты можно переписать (git amend, git rebase -i, разбив на логически связанные. Если ветка опубликована (транк), этого делать не рекомендуется, для feature branch можно изголяться по-всякому).

Один очевидный кандидат на feature branch: ветка для багфиксинга. То есть, правим баги в одной ветке, не ломая транк, и сливаем пофикшенное в транк.

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

> Я сравниваю DVCS и svn не вообще, а применительно к совершенно конкретному случаю. И вовсе не утверждаю, что «git не нужен». Я утверждаю, что «в данном случае, применение svn более оправдано».

В данном случае, что git (msysgit), что hg (tortoiseHg с батарейками), что SVN (Tortoise SVN) — одинаково. Другое дело, что DVCS
а) позволяют организовать более гибкий workflow
б) более эффективны при обновлениях
в) в большей степени socialware, чем SVN — взял проект на github, форкнул, получил результат и послал автору pull request, он взял и подгрузил в апстрим. Чем по сравнению: получить доступ к коммиту SVN, медленно и печально сделать коммит, обсудить его и дальнейшее направление развития в какой-то вики.

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

> насколько хорошо они поддаются дельтификации. Потому что одно дело видеоролик на пол-гига, другое - битмап на 100 метров. И еще важен поток изменений - если 2/3 изменений делаются на медийных файлах, это уже не софтверный проект.

конкретно в модах к игрушкам есть 2 варианта: делать ресурсы самому или использовать уже готовые из стандартных кампаний. Понятно, что во втором случае можно сильно сэкономить. Если делать ресурсы самому, то тоже есть разница, то ли это текстура или звук, то ли модель-исходник, то ли «скомпимпилированный уровень», то ли это скрипт. Поэтому очень большая разница будет скорее всего в проектах типа Black Mesa Source, где все текстуры свои, модели свои доработанные, и т.п.
Да и то я сомневаюсь, что там на каждый чих все текстуры правят.
Можно не хранить в репозитории «скомпилированный уровень», а только его исходник, но это уже извращение в некотором роде, для облегчения тестирования.

И еще важен поток изменений - если 2/3 изменений делаются на медийных файлах, это уже не софтверный проект.


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

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

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

Интересно. Можно ли у вас закоммитить код, соответствующий квесту, который невозможно пройти ? :))
И насколько то, что такой код поломанный — существенно для проекта в целом (его квесты-зависимости при топологической сортировке)?

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