React repository is 13700 commits by 1624 authors in 1921 files resulting in 500K lines. Code on JavaScript is about 350K lines.

JavaScript code burndown by year:JavaScript code ownership by author with 5% threshold:

Initially, MSR Tools was designed for SVN and then poorly adapted for GIT. As a result, it had serious limitations with branch processing which makes it inapplicable for most GIT repositories. Another problem was about infrastructure which requires the installation of MS SQL Server. Project configuration via container XML-files was truly unintuitive and user-unfriendly.

But time does not stand still. Ten years ago there was no .NET Core, Docker or React. Now we have it all and it makes things so different. Using some modern approaches I have reimplemented the core idea of old software to make a new one. Meet Repositorch: a version control system analysis engine written in C#.

Right now Repositorch is focused on getting and representing code metrics based on repository evolution. It is easy to use solution, which works on Linux or Windows and allows you to mine some really interesting stuff. Check ten minutes “how to use” guide:

За основу была взята идея простой физической симуляции шаров в ящике, управляемой положением мобильного устройства. Этакая пространственная вариация на тему цветных шаров, по мотивам которых существует много так называемых “тайм-киллеров”. Периодически безмятежность процесса прерывалась различными тонкими моментами, фичами, багами, с которыми пришлось в разной степени мириться/бороться.

Прежде всего

пришлось обновиться до актуальной версии кода. Последняя стабильная версия 3.6 фактически не имеет поддержки OpenGL ES 3 и с поддержкой более ранних версий тоже справляется плохо, демонстрируя стабильные вылеты.

Доступ к ресурсам

по началу может стать причиной неожиданных ошибок в процессе исполнения. Дело в том, что Android основан на ядре Linux и потому обладает свойством чувствительности к регистру символов в именах файлов и путях к ним. Несовпадение регистра символов никак не проявляется при работе в Windows. Но стОит запустить тот же самый код на Android и приложение валится при попытке загрузки ресурсов.

Графика и все что с ней связано

предсказуемо стала источником большинства проблем, как и в случае перехода с XNA на MonoGame. Пришлось довольствоваться возможностями shader model 3 и мириться с большим количеством ограничений. Так например нет возможности использовать floating point render target. А значит для хранения например глубины сцены придется пользоваться какими-нибудь схемами кодирования.

Вертексные и индексные буферы имеют метод GetData. Он позволяет вытащить геометрию из уже созданных буферов, что может быть полезно например для создания модели физики для уже загруженной 3D-модели. Метод хоть и не самый быстрый, но очень удобный. Работая без проблем на десктопе, на мобильной платформе не поддерживается. А без него придется либо править Content Pileline, либо формировать упрощённую физическую модель другими методами.

Среди параметров растеризации есть FillMode, который будучи установленным в значение WireFrame, позволяет отрисовывать только полигональную сетку. Опять же бывает очень удобно в процессе отладки. Однако для Android эта функция не реализована.

Использование семантик COLOR и NORMAL при передаче параметров в пиксельные шейдеры, приводит к невозможности эти параметры использовать. При этом нет ошибок компиляции или исключений в процессе исполнения. Приложение просто намертво зависает. Приходится плодить семантики TEXCOORD1, TEXCOORD2 и т.д.

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

float3 randomNormal(float2 tex)
{
  float noiseX = (frac(sin(dot(tex, float2(15.8989f, 76.132f) * 1.0f)) * 46336.23745f));
  float noiseY = (frac(sin(dot(tex, float2(11.9899f, 62.223f) * 2.0f)) * 34748.34744f));
  float noiseZ = (frac(sin(dot(tex, float2(13.3238f, 63.122f) * 3.0f)) * 59998.47362f));
  return normalize(float3(noiseX, noiseY, noiseZ));
}

Однако полученная таким образом текстура нормалей на мобильной платформе из-за меньшей точности отличается. Разница между правильным (слева) и неправильным (справа) результатами видна невооруженным глазом. Для решения этой проблемы проще всего пользоваться традиционной готовой текстурой.

Производительность

едва ли будет проблемой, если игра достаточно проста и использует спрайтовую анимацию. В моём случае требовалось отрисовывать трехмерную сцену с эффектами и выполнять физическую симуляцию. Не слишком древний аппарат на 4-м Android’е захлебывался очень быстро. Более свежий аппарат на 7-м Andriod’е показывал лучшие результаты, но не идеальные. Вынос физики в отдельный поток решил проблему. Остальной код к асинхронной работе физики оказался готов. Почти… Лишь спустя какое-то время на записи видео игрового процесса удалось разглядеть рассинхрон между геометрией и затенением для неё. Причина была в обновлениях физики, которые вклинивались между формированием двух картинок. Исправить оказалось легче, чем заметить.

Причиной менее очевидных проблем может стать JIT-компиляция. И тут следует зайти из далека. Если не рассматривать различные варианты обфускации, то есть всего три варианта сборки, от выбора которых зависит что в итоге будет содержать результирующий APK-файл:

1. Все ваши библиотеки в неизменном виде. Вариант по умолчанию. Худший вариант ибо и размер APK-файла большой и код абсолютно открыт для исследования/модификации/заимствования.

2. IL-код ваших библиотек интегрированный в нативные бинарники (опция “Bundle Assemblies into Native Code”, доступна в Enterprise версии). Позволяет значительно сократить размер APK-файла и усложнить любые манипуляции с кодом.

3. Нативный код (опция “AOT Compilation”, доступна в Enterprise версии). Позволяет сократить время запуска и максимально усложнить манипуляции с кодом, но размер APK-файла снова большой.

В первых двух случаях APK-файл содержит IL-код ваших библиотек, который подвергается JIT-компиляции в процессе исполнения. Но не сразу и не весь, а по мере необходимости и частями. Поэтому если так случается, что значительный объем кода до некоторого момента времени не использовался, а потом вдруг понадобился, то его JIT-компиляция может оказаться достаточно продолжительной для того, чтобы привести к заметному притормаживанию. В игровых приложениях это приводит к падению частоты кадров, что конечно крайне нежелательно. Если подобные эффекты слишком заметны, то есть лишь два варианта: либо использовать AOT-компиляцию, либо выполнять прогоны целевого кода на этапе загрузки, чтобы в последствии не тратить время на JIT-компиляцию.

В итоге

каких-то специфичных только для MonoGame трудностей возникло немного. Это лишний раз подтверждает зрелость библиотеки и её готовность для решения подобных задач. Конечно сегодня, учитывая существование и относительную доступность таких движков как Unity, подобные методы можно охарактеризовать как скорее неверные. По крайней мере, если главной целью является быстрое достижение результата. Тем не менее, эти методы все же работают и нашли воплощение в игре BusyBalls.

Начать проще простого. Идём на официальный сайт и загружаем версию для Visual Studio. Сразу после установки появляются шаблоны проектов MonoGame.

Или не появляются… В этом случае проблема может быть в том, что в настройках Visual Studio был изменён путь к каталогу с шаблонами и придётся скопировать их вручную из каталога где обычно находятся шаблоны проектов C:\Documents and Settings\UserName\Documents\Visual Studio 2013\Templates\ProjectTemplates\Visual C#.

Выбираем проект для той платформы, которая нам нужна и вперёд. Я выбираю Windows Project, т.е. проект для ОС Windows использующий DirectX в качестве графического API. Естественно, вновь созданный пустой проект тут же можно скомпилировать, запустить и узреть пустой экран закрашенный цветом васильков, он же CornflowerBlue.

В последних версиях MonoGame работа с контентом стала наконец такой же удобной как и при использовании XNA. И даже лучше. Больше не нужно никаких Content Project! Прямо в основном проекте теперь есть файл Content.mgcb, при попытке редактирования которого открывается новая утилита MonoGame Pipeline, предназначенная для добавления ресурсов в наше приложение.

Добавим какую-нибудь модель в формате .fbx и текстуру для неё. Выполним билд (F6). Утилита должна рапортовать об успехе. Радует, что запускать её придётся только для добавления новых ресурсов. При редактировании ранее добавленных их перекомпиляция выполняется автоматически при построении проекта в Visual Studio, а в случае неудачи причины сразу видны в окне Error List.

Теперь попробуем отрисовать нашу модель. Для этого нам понадобится объявить несколько переменных для модели, текстуры и эффекта.

Model model;
Texture texture;
Effect modelEffect;

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

model = Content.Load<Model>("Statue");
texture = Content.Load<Texture2D>("Bronze");
modelEffect = Content.Load<Effect>("Model");
modelEffect.Parameters["world"].SetValue(Matrix.CreateFromYawPitchRoll(-1,0,0));
modelEffect.Parameters["projection"].SetValue(Matrix.CreatePerspectiveFieldOfView(
    MathHelper.ToRadians(90),
    graphics.GraphicsDevice.Viewport.AspectRatio,
    0.01f,
    100.0f
));
modelEffect.Parameters["view"].SetValue(Matrix.CreateLookAt(
    new Vector3(15, 20, 15),
    new Vector3(0, 25, 0),
    Vector3.Up
));
modelEffect.Parameters["colorMap"].SetValue(texture);

В метод Draw добавим код для отрисовки модели с нашим кастомным эффектом.

protected override void Draw(GameTime gameTime)
{
    GraphicsDevice.Clear(Color.Black);

    modelEffect.CurrentTechnique = modelEffect.Techniques["Model"];
    modelEffect.CurrentTechnique.Passes[0].Apply();
    foreach (ModelMesh mesh in model.Meshes)
    {
        foreach (ModelMeshPart meshPart in mesh.MeshParts)
        {
            graphics.GraphicsDevice.Indices = meshPart.IndexBuffer;
            graphics.GraphicsDevice.SetVertexBuffer(meshPart.VertexBuffer);
            graphics.GraphicsDevice.DrawIndexedPrimitives(PrimitiveType.TriangleList, 0, 0, meshPart.NumVertices, meshPart.StartIndex, meshPart.PrimitiveCount);
        }
    }    
    base.Draw(gameTime);
}

Далее переходим к коду шейдера на языке HLSL. В нём нам понадобятся переменные для ранее заданных матриц и текстуры.

float4x4 world;
float4x4 view;
float4x4 projection;

Texture2D colorMap;
SamplerState filter : register(s0);

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

graphics.GraphicsDevice.SamplerStates[0] = new SamplerState()
{
    AddressU = TextureAddressMode.Clamp,
    AddressV = TextureAddressMode.Clamp,
    Filter = TextureFilter.Anisotropic,
    MaxAnisotropy = 8
};

Далее структуры для входа и выхода вершинного шейдера.

struct VSInput
{
    float3 Position : SV_POSITION;
    float3 Normal : NORMAL0;
    float2 UV : TEXCOORD0;
    float4 Color : COLOR0;
};
struct VSOutput
{
    float4 Position : SV_POSITION;
    float4 WorldPosition : COLOR0;
    float3 Normal : NORMAL0;
};

Вершинный шейдер лишь трансформирует координаты вершин и нормали в соответствии с указанными матрицами.

VSOutput ModelVS(VSInput input)
{
    VSOutput output;
    
    output.WorldPosition = mul(float4(input.Position, 1), world);
    float4 viewPosition = mul(output.WorldPosition, view);
    output.Position = mul(viewPosition, projection);
    output.Normal = mul(float4(input.Normal, 1), world).xyz;
    
    return output;
}

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

float4 ModelPS(VSOutput input) : SV_TARGET0
{
    float2 uv = float2(
        snoise(input.WorldPosition.xyz*2),
        snoise(input.WorldPosition.zxy*2)
    );
    float3 color = colorMap.Sample(filter, uv).rgb;    
    
    return float4(color, 1);
}

В самом конце создаём однопроходную технику использующую вершинный и пиксельный шейдеры.

technique Model
{
    pass Pass1
    {
        VertexShader = compile vs_5_0 ModelVS();
        PixelShader = compile ps_5_0 ModelPS();
    }
}

Данный шейдер расcчитан на использование DirectX 11. В дополнение можно прикрутить примитивное освещение от одного источника и увидеть результат.

Проект для Visual Studio доступен здесь.

Портирование готового проекта с XNA на MonoGame в текущих реалиях является относительно несложной задачей. Потребности править код скорее всего не будет. Единственное несоответствие API XNA, с которым я столкнулся это отсутствие метода Transform у структуры Matrix. Если сложности и возникнут, то они будут связаны с шейдерами. Самое большое неудобство – крайне агрессивная оптимизация вне зависимости от того выполняется построение DEBUG или RELEASE версии проекта. Как следствие, стоит только в шейдере не воспользоваться текстурой, как переменная для неё исчезает и получаем ошибку исполнения при попытке установить соответствующий параметр шейдера. Раздражает…

Для Windows мы можем выбирать между двумя графическими API: OpenGL и DirectX. Выбирая первое, как и в XNA мы будем ограничены возможностями шейдеров модели 3.0. При этом код на HLSL будет при компиляции транслироваться в GLSL. Выбирая DirectX, мы теоретически можем пользоваться возможностями шейдеров вплоть до модели 5.0, но только теоретически. Пока что MonoGame поддерживает только вершинные и пиксельные шейдеры, а значит самые интересные возможности DirectX 10 и 11 остаются недоступными. Многие относительно простые вещи, которых по понятным причинам не могло быть в XNA, отсутствуют и в MonoGame. Метода для генерации mipmap нет, возможности прочитать hardware-глубину нет и т.д. Разумеется всё решаемо. Исходный код MonoGame доступен и при желании всё необходимое можно доделать. Что-то делается совсем просто, что-то сложнее…

Утилита для компиляции ресурсов также не лишена проблем. Они часто возникают при обработке .fbx моделей. Иногда проблема – лишь следствие устаревшего формата входного файла и решается повторным экспортом из blender в новый формат. Иногда это не помогает. Обработка текстур с неполным набором каналов также может быть неудачной.

Поводя итог… Использование MonoGame никогда не было совсем безболезненным процессом и сейчас таковым не является. Но теперь настал тот момент, когда можно говорить о достаточной зрелости проекта, чтобы те кто до сих пор не отказался от XNA наконец сделали это. Хотя бы по той причине, что MonoGame продолжает развиваться. Пусть и не так быстро как хотелось бы…

Click to see full-sized image.

f2-classic-1

f2-old-1

f2-new-1

f2-classic-2

f2-old-2

f2-new-2

f2-classic-3

f2-old-3

f2-new-3

It works with Steam version and looks pretty well for me. Just place shader at \data\shaders under your fallout installation and set “Mode=4” and “GlobalShaderMode=3” in ddraw.ini. For those who remember classic…

Update:

With sfall 3.0 and higher you need to use the following mod. Just place shader blur.fx at \data\shaders and script glblur.int at \data\scripts under your fallout installation and set “Mode=4” in ddraw.ini. It works with high resolution patch. Unfortunatly current sfall 3.1 does not set correct screen resolution for shaders. So you will have to change “resolution” variable in shader blur.fx manually via any text editor. The default is old-school 640×480.

Fallout 2 blur shader 2.27 KB

Download

]]> http://kirnosenko.com/2013/07/21/fallout-2-global-shader/feed/ 1 271 http://kirnosenko.com/2013/04/22/where-should-freelancer-go/ Mon, 22 Apr 2013 13:05:35 +0000 http://kirnosenko.com/?p=248 В 2002 году я стал студентом и начал осваивать азы компьютерных наук. Всё было ново и интересно. В те времена я увлекался программирование простых игр, но однажды бросил это занятие руководствуясь соображением о том, что это “не серьёзно”. С тех пор в качестве кустаря я попробовал себя на разных поприщах. И вот спустя 10 лет я задумался а не вернуться ли к старому увлечению? И дело не в том, что я поменял своё мнение. Просто за прошедшее время мир очень сильно изменился.

Конец 90-х и начало 2000-х стали “золотым веком” shareware ПО. Взяв на вооружение доселе невиданные средства быстрой разработки, многие кустари принялись интенсивно осваивать новые рынки. Часто за официальным сайтом и гордым именем вроде MegaSuper Software скрывался кустарь в единственном числе, который сидя дома в нижнем белье изображал из себя одновременно разработчика, управленца, сотрудника техпомощи и ещё чёрт знает кого. Подтянувшиеся на спрос сервисы-регистраторы позволяли живя в каком-нибудь Мухосранске продавать плоды своего труда по всему миру. Многие кустари, пользуясь пробелами в законодательстве и в грамотности банковских работников, даже не утруждали себя оплатой налогов. При удачном стечении обстоятельств жизнь могла быть легка и прекрасна, что для того времени было редкостью. Но этот праздник жизни не мог продолжаться вечно. Со временем перенасыщение рынка, развитие движения open-source и ряд менее важных причин привели к резкому падению спроса. Причём во всех массовых нишах. Подобные испытания заставили ряды кустарей-софтоделов сильно поредеть. Это у нескромных стартаперов был быстрый кризис доткомов. А для скромных кустарей-софтоделов смерть была медленной и мучительной. Множество программ часто востребованных и весьма неплохих канули в небытие просто потому что их разработка стала невыгодной. Сегодня же разработка собственной “коробки” для кустаря – практически самоубийство. Широкие ниши заняты очень качественными решениями, часто абсолютно бесплатными, а то и вовсе распространяемыми с открытым исходным кодом. Узкие же ниши слишком узки и выживание в них обычно требует либо крупных начальных капиталовложений либо наличия с потенциальными клиентами более осязаемых связей нежели Интернет.

Потом пришла волна популяризации фриланса. Работодатели созрели для того, чтобы отдавать работу на сторону, а вчерашние офисные моллюски созрели для того, чтобы зарабатывать подобными вещами на жизнь. Многие из бывших кустарей-софтоделов подались во фриланс. Что давалось им не легко, т.к. требовало смены парадигмы. Ещё вчера ты продавал одно и то же много раз разным клиентам, а теперь делаешь для каждого клиента что-то уникальное. Удельная стоимость работы падает однако! Но и так жить можно. Хотя и фриланс не обошли катаклизмы эволюции. Периодические нашествия нано-гастарбайтеров готовых сворачивать горы за копейки. Постепенная трансформация отдельных фрилансеров во фриланс-организации способные формировать нечеловеческие портфолио и проводить демпинг. Короче ещё одна “лодка разбилась о быт”.

А история между тем имеет тенденцию повторяться. И вот что однажды произошло со средствами быстрой разработки теперь случилось с графическими и игровыми движками. А именно их стало много, они стали действительно доступными и качественными. Сегодня найти движок под любимую платформу и любимый язык программирования легче, чем десять лет назад найти дистрибутив linux под свой cd-привод! Значительно увеличилось число потенциальных платформ: смартфоны, планшеты, консоли всех мастей, социальные сети, да и старушка персоналка пока не сдаётся. Каждая платформа предоставляет уникальное сочетание возможностей, что в свою очередь позволяет реализовывать самые разные идеи и прививать их там где у них больше всего шансов прижиться и максимально раскрыть свой потенциал.

Если так происходит, значит на то есть причины. И они заключаются разумеется не только в том, что технологически процесс создания игр становится более простым и доступным. Куда более важные причины – популяризация цифровой дистрибуции и конечно рост спроса! Сегодня глядя на то как развиваются Steam и Desura, глядя на то чем прирастает Kickstarter становится ясно, что спрос растёт и растёт быстро. Самое любопытное заключается в том, что все эти кризисы, финансовые и не очень, совсем не вредят игровой индустрии. Скорее даже наоборот. А всё почему? Потому что развлечений хочется всегда, а в тяжёлые времена их хочется вдвойне. Интерактивные же развлечения – пожалуй самые доступные. Отдал 50 баксов за какой-нибудь Skyrim и “развлекайся” целый месяц. Куда уж дешевле?!

Улавливая ветер перемен кустари уже несколько лет активно идут в игровую индустрию. Но и здесь не всё благополучно. На любом поприще главный враг кустаря – большие и средние “игроки” на рынке. Они появляются везде где есть деньги и часто подобно саранче не оставляют за собой ничего. Игровая индустрия – одна из немногих где спроса хватает на всех, кто в состоянии предложить что-то более или менее интересное. Но как долго это продлится? Экспансия больших студий не останавливается, а рынок насыщается стремительными темпами. Разумеется сила “инди” в оригинальности и нестандартности, которые большие студии часто не могут себе позволить. Многие приводят это в довод тому, что “инди” и большие студии всегда будут занимать две разные ниши. От части это так, но в то же время глупо отрицать влияние этих двух кусков рынка друг на друга. А влияние в любой момент может привести к смене соотношения сил.

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

Таинственный коммит

Суть: Комментарий к коммиту не несёт полезной информации либо вовсе отсутствует.

Причины: Лень и ничего больше.

Проблемы: О назначении коммита можно судить лишь ознакомившись с набором изменений входящих в него. Как следствие, постоянные трудности при поиске определённых коммитов, попытках переноса коммитов между ветками и т.п. Каждый раз когда вы хотите что-то сделать с коммитом неизбежно возникает вопрос: “А тот ли это коммит, который мне нужен?”

Решения: Пишите, мать вашу, комментарии! Желательно более предметные чем “bug fixed” или “some stuff added”.

Многоцелевой “баллистический” коммит

Суть: Коммит содержит набор изменений не связанных между собой.

Причины: Лень, недостаточный опыт эксплуатации систем контроля версий.

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

Решения: По хорошему любой несервисный коммит (не связанный с созданием/слиянием веток и т.п.) должен иметь целью одно из трёх действий: добавление новой функциональности, выполнение рефакторинга, исправление дефекта. Дробя коммиты по содержимому мы естественным образом реализуем принцип “разделяй и властвуй”. Не бойтесь сделать несколько коммитов вместо одного. Система контроля версий от этого не лопнет, а вы в перспективе только выиграете.

Выгребная яма

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

Причины: Лень, недостаточная осведомлённость о назначении и принципах работы систем контроля версий.

Проблемы: Засорение репозитория временными файлами, файлами IDE не несущими полезной информации, бинарными файлами сборок (в совсем запущенных случаях). Ситуация с бинарными файлами осложняется тем, что для них проблематично отслеживание изменений. И даже когда в репозитории находятся только действительно нужные бинарные файлы (сторонние библиотеки, ресурсы приложения и т.п.), если объём и количество их велико и они часто меняются, то размер репозитория может очень быстро вырасти до непристойных размеров.

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

Черенок

Суть: Использование веток сведено к минимуму и от них отказываются даже в тех случаях когда они показаны, практически вся разработка ведётся на trunk’е.

Причины: Лень, недостаточный опыт эксплуатации систем контроля версий.

Проблемы: Даже частичный отказ от использования веток может привести к значительным трудностям при управлении изменениями. Разве приятно выполнить одну и ту же работу несколько раз, выкинуть почти работающий код или сохранить его дедовскими методами типа архивирования репозитория, не иметь возможности выпустить промежуточный релиз в любой момент времени?

Решения: Учиться, учиться и учиться. Есть много материалов хорошо разъясняющих что, зачем и как.

Заросли

Суть: Ветки используются чрезмерно интенсивно, даже в тех случаях когда существуют более простые средства решения задачи. При этом trunk может выглядеть примерно вот так:

Причины: После subversion простота и легковесность веток в том же git безусловно воодушевляет и мотивирует на великие свершения.

Проблемы: При большом числе веток и интенсивном их пересечении восприятие основного тренда разработки может быть сильно затруднено. Также растёт вероятность допущения ошибок при работе с ветками.

Решения: Разумеется ветки полезны и отказываться от них нет смысла. Но не следует делать простые вещи сложными путями. В git например есть fast-forward merging, который позволяет скрыть следы того, что ветка вообще была. А применение иерархии параллельных веток с последовательным слиянием позволяет упростить trunk, не засоряя его кучей feature branch’ей. Репозиторий postgresql хороший пример того, что даже в крупном проекте trunk может быть прямым и изящным.

Блуждающий ствол

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

Причины: Недостаточный опыт эксплуатации систем контроля версий.

Проблемы: Если вы создали некоторую структуру веток, а потом не знаете как сделать с ними простые вещи типа релиза, то вы определённо делаете что-то не так.

Решения: Можно выделить два типичных подхода к организации основных ветвей разработки. Подход номер раз: Стабильный trunk. На trunk’е всегда стабильный код, который собирается, проходит тесты и прочее. Разработка ведётся на дополнительных ветвях. Как только всё необходимое в такой ветке реализовано и проверено ветка сливается на trunk. Возможна многоуровневая иерархия таких веток, что позволяет работать даже с очень большими объёмами кода. По ходу разработки на trunk’е появляются тэги версий. Подход номер два: Активный trunk. На trunk’е самый последний код, который может даже не собираться. По мере реализации функциональности от trunk’а отделяются ветки версий. В дальнейшем в них заносятся только исправления и на них же появляются тэги версий. Первый подход удобен для изоляции изменений, второй – для поддержки множества версий. Необходимость в более сложных вариациях на практике возникает редко.

Мораль: Часто соблюдение простых правил требует гораздо меньше времени чем время, которое придётся потратить на борьбу с последствиями несоблюдения этих правил.

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