из Subversion в Mercurial

Если вы не знаете, как смотреть историю в mercurial, то может вам рановато на него переезжать.

З.Ы. А по сабжу hg convert.

Речь не идет о том "как" перенести. Это уж мы как-нибудь. Вопрос чё дальше? Как пропагейшн делать? Конкретно на вопрос сможешь ответить, если такой опытный? Как посмотреть историю конкретной папки? Когда она была создана, историю копий. Мож я чё не понимаю, мож там такого вообще нет? 8-\

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

> Как пропагейшн делать?

А что - есть выбор? :D Mercurial - это не SVN, hg pull и hg merge - твое ффсио.

> Как посмотреть историю конкретной папки?

Какой еще папки? O_o Каталога, чтоли? Никак. Если сильно надо - hg log -v -f имякаталога/имяфайлавкаталоге.

> историю копий

Это что такое? ;)

> Мож я чё не понимаю

Да.

> А что - есть выбор? :D Mercurial - это не SVN, hg pull и hg merge - твое ффсио.
не густо, однако ((

>> историю копий 
>Это что такое? ;)

$svn log -v destination/

------------------------------------------------------------------------
r24 | xx | 2009-01-03 14:53:22 +0100 (Sat, 03 Jan 2009) | 1 line
Changed paths:
   A /destination (from /source:23)

copied destination
------------------------------------------------------------------------
r23 | xx | 2009-01-03 14:52:47 +0100 (Sat, 03 Jan 2009) | 1 line
Changed paths:
   A /source

created source
------------------------------------------------------------------------

>>> историю копий

>>Это что такое? ;)

>$svn log -v destination/

Ы... man ирония

Объясняю для людей без чувства юмора: вы используете сильно специфичные для SVN фишки, которые в Mercurial не будут работать так, как вы ожидаете. Наскольяко я понимаю, вы храните в одном репозитории несколько независимых проектов, это просто не то, для чего создавался Mercurial. Я не знаю, на чем вы обломаетесь, если механически перенесете свои SVN-привычки в Mercurial, но вы обломаетесь.

Но если сильно хочется, поддеревья копировать можно, и hg log -C -v покажет, что оно было скопировано.

> Какой еще папки? O_o Каталога, чтоли? Никак.
Да это просто VSS какой-то!

> Если сильно надо - hg log -v -f имякаталога/имяфайлавкаталоге.
Файла. Ага. Его история совсем ничего не скажет о том как жил компонент (каталог тоесь). Учитывая еще и то, что таких файлов для каждого каталога дофига и у каждого своя нелегкая судьба.

>> Какой еще папки? O_o Каталога, чтоли? Никак.

> Да это просто VSS какой-то!

Как скажешь.

>> Если сильно надо - hg log -v -f имякаталога/имяфайлавкаталоге.

>Файла. Ага. Его история совсем ничего не скажет о том как жил компонент (каталог тоесь)

Ну, если тебе не скажет - может, тебе и правда рано на Mercurial? Hint: это даст тебе все переименования каталога (плюс еще шумы, но их придется отфильтровать).

Почитай вводные главы Mercurial Book.

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

Объясняю для тех, кто невнимательно читает по-русски. Это один проект, но для разных платформ. Хорошо, я уже согласен положить каждый в отделную базу hg. Вопрос тогда как мне переносить одинаковые компоненты туда-сюда. А если с момента "бренча" изменения будут в обоих проектах? Как не потерять? И как вообще видеть движуху компонентов между проектами?

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

В принципе, в mercurial уже есть какое-то дополнение, реализующее функции этого "скрипта", называется forest что ли. Не помню точно.

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

> Объясняю для тех, кто невнимательно читает по-русски

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

> Хорошо, я уже согласен положить каждый в отделную базу hg.

Ы. Что такое "база hg"? :) Эти ваши "проекты" - на самом деле 3 ветки одного проекта, так что им логично жить в клонах одного репозитория. Ты клоны называешь "базами"?

> Вопрос тогда как мне переносить одинаковые компоненты туда-сюда.

Кошерное решение будет включать в себя вынесение компонентов в отдельные репозитории и использование расширения forest.

> Как не потерять?

Хренассе. Что значит "не потерять"? Ты даже в SVN используешь copy вместо merge, просто напрашиваясь на потери. В любом случае, чтобы "не потерять" - hg merge.

> И как вообще видеть движуху компонентов между проектами?

Выражайся яснее, а? На литературном русском, если можешь.

> Для каждого компонента и каждого проекта создаёте отдельный репозиторий.
Вобщем, идея ясна. Технически это сработает, но для каждого компонента... Стало быть, около 20-30 баз на один проект. Боюсь коллеги меня не поймут, а мне хотелось бы ещё немного пожить. ;)
Это слишком высокая плата за те плюсы, которые даёт hg.

> Стало быть, около 20-30 баз на один проект.

Зависит от того, кто их разрабатывает, и насколько часто они меняются. Технически ничто не мешает их сложить их в один репозиторий.

> Это слишком высокая плата за те плюсы, которые даёт hg.

Используемая на всю мощь SVN - это просто финиш. Lock-in, из которого невозможно выбраться :)

> Используемая на всю мощь SVN - это просто финиш.
Если бы мне не нужна была его мощь, то я бы пользовался мощью файловой системы. :)

> Что такое "база hg"?
Для меня - это каталог .hg со всеми его/её клонами.

> Эти ваши "проекты" - на самом деле 3 ветки одного проекта, так что им логично жить в клонах одного репозитория.
Предположим. Я сам не знаю как им логично. Я ищу решение.

> Кошерное решение будет включать в себя вынесение компонентов в отдельные репозитории и использование расширения forest.
Ты сам себе противоречишь. Давай выбери либо "жить в клонах одного репозитория", либо "отдельные". Про форест посмотрю потом. Может это ОНО.

> Хренассе. Что значит "не потерять"? Ты даже в SVN используешь copy вместо merge, просто напрашиваясь на потери.
Вот тут мы подходим к самому вкусному. При попытке замещения одной ветки компонента (каталога) на другую (обновленную ветку из параллельного проекта), в случае обнаружения изменения после брэнча в заменяемой, загорается лампочка и раздаются три красных свистка вверх. Копирование не происходит и ничего не теряется.

> Выражайся яснее, а? На литературном русском, если можешь.
Хорошо, попробую со словарем. Возьмем за отправную точку ту идею, что все три параллельных проекта лежат в одном репозитории HG. Как разные головы или параллельно - не знаю ещё. Предположим, параллельно. Предположим дальше, что в компоненте (каталоге) px/a были сделаны изменения, протестировано, сделан тэг и ушло в продакшн. Далее принимается решение обновить py/a из px/a. Теперь вопросы:
1. Как мне посмотреть действительно ли py/a является брэнчем px/a?
2. Как мне убедиться, что после брэнча, в py/a не было сделано изменений, которые могут быть потеряны после очередной копии. Если HG это всё умеет делать автоматом, то я буду только рад. Но как?

На мой вкус у тебя очень извращенная схема. Я правильно понимаю, что разные каталоги одного проекта должны по-разному фиксировать изменения? Т.е. некоторые из них являются разделяемыми и просто сделать commit для них нельзя, надо еще (возможно, не сразу, но сути это не меняет) их откопировать во все остальные проекты?

По сути, есть несколько составных проектов, с независимыми частями, некоторые из которых входят в несколько проектов сразу. По крайней мере, это следует из описания. Тогда каждая часть - это автономная сущность и управлять ей следует тоже автономно. Т.е. каждый компонент - отдельный проект с точки зрения системы контроля версий. Для каждого проекта с точки зрения человека можно делать всякие упрощающие жизнь скрипты (получить все компоненты проекта, обновить и т.д.). Тогда все просто с ветвями и историей.

Если так делать очень не хочется, можно сделать один проект (с точки зрения системы контроля версий), одно дерево исходников, из которого будут собираться все проекты (с точки зрения человека). Даже если для разработки используется такой ужоснах, как MSVS, то делается такая штука элементарно - кладем несколько solution'ов и все дела. С ветками, в принципе, тоже проблем нет, есть некоторая избыточность - каждая копия дерева исходников будет содержать все исходники, даже если нужно работать только над одним проектом (с точки зрения человека).

Проблем со сборкой одного проекта (с точки зрения человека) с одной версией тех или иных компонентов, а другого - с другой, нет в любом случае - ветви это обеспечивают. Только надо сразу осознать, что в распределенных системах контроля версий каждая копия дерева исходников - это репозиторий/ветвь. И смириться с накладными расходами на это (или продолжать использовать SVN).

> Т.е. некоторые из них являются разделяемыми и просто сделать commit для них нельзя, надо еще (возможно, не сразу, но сути это не меняет) их откопировать во все остальные проекты?
Нет. Все проекты, или, строго говоря, все версии проекта для всех платформ, сейчас абсолютно независимы. Если тебе надо делать фикс в одном из компонентов одного из проектов, ты его делаешь не боясь, что сломаются остальные. Больше ничего не "надо". Если другой проект имеет такой-же компонент, то ты можешь заменить его на исправленный вышеописанной технологией. Можешь это сделать сразу, а можешь после накопления критической массы сделанных фиксов или фич. Причем, можешь делать это перекрестно, если одни компоненты менялись в одном проекте, а другие - в другом.

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

> Т.е. каждый компонент - отдельный проект с точки зрения системы контроля версий.
Уже думал над этим. Минус в том, что если фиксятся два компонента, взаимодействующих между собой, то это будет два разных коммита в двух разных репозиториях. И потом, концепцию "один проект - несколько репозиториев" я нахожу несколько нездоровой. Как потом тэги ставить? Как эти тэги потом смотреть? Скриптами? Бред какой-то.

> Если так делать очень не хочется, можно сделать один проект (с точки зрения системы контроля версий), одно дерево исходников, из которого будут собираться все проекты (с точки зрения человека).
Если я правильно понимаю, то предлагается свалить компоненты от всех проектов в одну кучу, и туда же запихать все солюшены, каждый из которых будет использовать только часть компонентов? Как раз от такой модели когда-то ушли. Это настоящий хаос. Всё это умножается на несколько head'ов, если я правильно следую ходу мысли. По одному на каждый проект. Соответственно, каждая голова hg будет иметь все солюшены. При таком подходе люди обязательно будут менять проекты, не в том месте. Потом, я не совсем вижу как это решает проблему распространения компонентов. Мерж? А если мне надо замержить из одного проекта в другой не все компоненты, а только часть? А часть оставить на потом? Путаница гарантирована.

Вобщем, я медленно прихожу к выводу, что про hg можно забыть.

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

Да, я так и понял. И кто-то вручную время от времени синхронизирует их общие части.

> Не совсем так. Части не независимы, а взаимодействуют между собой.

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

> Минус в том, что если фиксятся два компонента, взаимодействующих между собой, то это будет два разных коммита в двух разных репозиториях. И потом, концепцию "один проект - несколько репозиториев" я нахожу несколько нездоровой

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

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

Если все вместе - это действительно один, монолитный проект, но в немного разных воплощениях для разных платформ или чего бы то ни было, то это нормально. Довольно часто делают в дереве исходников помимо каталого doc, src и проч. - win, unix, os2 и т.д., где лежат части, специфичные для конкретных платформ. Никакого хаоса - это вопрос организации.

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

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

Конечно, в Darcs, к примеру, ничто не мешает сымитировать такую логику. Просто в имя патча, относящегося к компоненту X, добавляем метку "компонент X". Патчи, естественно, должны затрагивать только один компонент за раз. Когда нужно сделать копию компонента в другом репозитории (или в другой ветке, что тоже самое), просто копируем туда все патчи с этой меткой. Если там уже был этот компонент, то предварительно удаляем оттуда все патчи с этой меткой. А если там не было изменений в этом компоненте, то и удалять не нужно - просто туда вольются все новые патчи, относящиеся к данному компоненту.

> Тот подход, что ты описал - он хуже.

Хуже, чем что? Этот метод прекрасно себя зарекомендовал на практике. Позволяет быстро вносить изменения в проект для определенной платформы, не оглядываясь на другие, и дает возможность легко и безопасно распространять багфиксы и новые фичи.

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

Ну нет такого - "влить изменения", нету! Ещё раз, компоненты не мержатся, а копируются. Старый шкаф выбрасываем, новый ставим на его место. А мерж - это когда ты начинаешь пилить старый шкаф до тех пор, пока он не становится похожим на тот, новый, что стоит в соседней комнате и один раз уже был допилен. И после копирования сохраняется вся история изменений из скопированного.

> При этом раньше (не знаю, как сейчас) SVN не умел при слиянии сохранять историю изменений из вливаемой ветки, следовательно, часть информации теряется (если, конечно, административно не запрещено одновременное изменение в нескольких вариантах одного компонента).

SVN умел копировать (и замещать) каталоги и раньше. Пользуемся им уже почти четыре года. Да, мерж-трэкинг появился только начиная с версии 1.5, но мы не мержим - нам этого просто не нужно. Ну или почти не. Это бывает настолько редко, что это даже и не пункт для обсуждения.

А что касается hg, то у него как раз функция отслеживания каталогов отсутствует. Кроме корневого, конечно. Для корневого все сделано супергут. Легкие бренчи, легкие мержи. Все ветки как на ладони. Вот если бы можно было увидеть историю любого каталога (компонента) ... А так - как ни крути, получается только хуже, чем есть.

Переход на Меркуриал не есть самоцель. Нет, так нет.

> Ну нет такого - "влить изменения", нету! Ещё раз, компоненты не мержатся, а копируются.

Это специальный случай merge - "всегда брать изменения из ветки N"

> Старый шкаф выбрасываем, новый ставим на его место.

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

> Вот если бы можно было увидеть историю любого каталога (компонента) ...

Посмотри всё же на forest.

> Хуже, чем что?

Чем то, что я пытаюсь предложить. Естественно, это лишь мое мнение, основанное на довольно поверхностном понимании ситуации.

> Ещё раз, компоненты не мержатся, а копируются.

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

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

> SVN умел копировать (и замещать) каталоги и раньше

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

> Переход на Меркуриал не есть самоцель. Нет, так нет.

Да я и не настаиваю. Сам я - любитель Darcs'а. А на работе - приходится плеваться, но использовать SVN. Но там вообще все очень запущено, ветки едва ли не я один использую, про теги и иные фишки вообще речи нет.

Посмотрите на hg transplant. Оно может подойти, но только в том случае, если не будет changeset'ов, затрагивающих И shared-компонент, И что-то локальное одновременно. Также можно посмотреть на hg q*, но может уже быть слишком мудрёным решением.

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

> Это специальный случай merge - "всегда брать изменения из ветки N"

У нас изменения берутся из любой ветки.

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

Ведется. Но как правило, если правится какой-то компонент, то это делается для одной платформы. Автоматический мерж svn'а при апдейте в рабочий каталог мержит очень хорошо. Даже если и меняются одновременно два аналогичных компонента для двух разных платформ, то эта ситуация обнаруживается при попытке распространении компоненты с одной пл. на другую. В этом случае смотрится взаимная история компонент. Уникальные коммиты набрасываются на параллельную компоненту, если они нужны. Потом эта обновленная компонента со всеми новыми фичами раздается всем (или некоторым) платформам.

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

Можно. Постом выше описал как это выглядит. Глянь.

> Это я и имел в виду, говоря, что такой подход хуже.

Это ты сам придумал. Стало быть, не хуже. ;)

> Чем то, что я пытаюсь предложить.

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

И вот тут начинается наступление на грабли. Поступает запрос на некую фичу для проекта px. Я сажусь и меняю, допустим, компоненты 'a' и 'x', которые взаимодействуют между собой. Тестирую, радостно хлопаю в ладоши, ставлю тэг, делаю push, релиз. Все счастливы. (ещё)

А в это время слетает проект py, который тоже использует компоненту 'a', т.к она у него она взаимодействует с 'y', которую никто не исправил. Хорошо, если не скомпилируется, тогда ночной билд это обнаружит. Если он есть. А если скомпилируется, но будет работать не так, как надо? И когда это обнаружится? И кем? Или меняешь одну платформу - тестируй все? Дороговато, однако.

А в нашем решении сорсы для всех платформ независимы. Меняешь px - py остаётся нетронутым. Если кто-то обновляет компоненты у py, то он делает это "здесь и сейчас" и он в курсе, чтО он меняет и должен это протестировать. И коммиты именно для этого проекта будут под его именем. Не проверил - сам себе злобный буратин.

Есть ещё одна грабля, но тут и так много текста.

> Посмотрите на hg transplant. Оно может подойти, но только в том случае, если не будет changeset'ов, затрагивающих И shared-компонент, И что-то локальное одновременно.

Тогда увы. :( Это как правило, но не гарантируется.

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

Общий кусок среди чего? У одной пары платформ - одно подмножество компонент общее, у другой - другое. Тут два вырожденных случая: все компоненты в одной куче и проекты их расшаривают (как предлагают сделать для hg), либо каждый проект содержит независимый набор компонент и только то, что нужно ему (как сейчас для svn). Середина - хаос.

Это не win, не linux, и даже не playstation. Эти чёртовы платформы появляются, как грибы с периодичностью раз в год. Я уже молчу об их ревиженах. И с такой же периодичностью исчезают. Одновременно живёт от трех до пяти штук. А софтварный продукт развивается и кочует с одной платформы на другую.

А чем не устраивает такой расклад:
 - forest для px (это все отдельные репозитории): 
   px
   px/a
   px/b
 - forest для py (это все отдельные репозитории): 
   py
   py/a
   py/c
 - forest для pz (это все отдельные репозитории): 
   pz
   pz/b
   pz/c
?
Здесь px/a и py/a просто клоны друг друга, и все изменения можно перетаскивать между ними свободно.
Можно, наверное, и еще один forest сверху прикрутить, если это нужно.

> Здесь px/a и py/a просто клоны друг друга, и все изменения можно перетаскивать между ними свободно.

Вернее, не "можно перетаскивать", а они сами перелезут. То есть, та же грабля, что и пару постов выше. Там, где начинается со слов: "А в это время слетает проект py ..." :(

> Вернее, не "можно перетаскивать", а они сами перелезут

С чего бы вдруг сами то? Пока не сделаешь push/pull ничего никуда не перелезит само.

> С чего бы вдруг сами то? Пока не сделаешь push/pull ничего никуда не перелезит само.

А как по твоему одни разработчики получают те изменения, которые были сделаны другими? Делаешь pull. Проблема тут в том, что ты не знаешь, то ли этот апдейт был сделан для проекта px, толи для py. Клоны...

На сервере, откуда все разработчики забирают изменения, также будут лежать разные репозитории px/a и py/a. Т.е. можно независимо вносить в них изменения. Ну и периодически их мержить, когда это необходимо.

То есть, уже не клоны? Ты уж определись тогда, а то я за твоей мыслью не поспеваю. Если так, то тогда два вопроса.

1. Можно делать переносы каталогов между разными репозиториями? В истории это видно?

2. Если я копирую из пункта А в пункт Б, то есть возможность убедиться, что в Б нет никаких уникальных коммитов, которых бы не было в А?

> То есть, уже не клоны? Ты уж определись тогда, а то я за твоей мыслью не поспеваю.

Разные репозитории px/a и py/a являются клонами. Но т.к. они физически лежат в разных местах, то при fpull/fpush (это команды из расширения forest) для проектов px и py никогда ничего автоматически не меняется в другом клоне. Т.е. все происходит так, как будто это вообще не связанные репозитории.

И происходит это вплоть до того момента, когда мы решили их смержить. Тут мы вспоминаем, что на самом деле это клоны одного и того же репозитория, вытаскиваем полные forest для px и py, и уже напрямую px/a <-> py/a делаем pull..merge..push

> Разные репозитории px/a и py/a являются клонами.

Понял. То есть, на сервере тоже клоны. По одному для платформы. Чем дальше в лес, тем больше баз. И это всё для одного проекта. То есть, каждый раз, когда появляется новая платформа мне надо идти к админу, чтобы он развернул мне весь набор клонов для очередной платформы. Хотелось бы исключить зависимость от него из процесса разработки. Не знаю, как на твой вкус, но по мне - это как-то муторно всё. Слишком много баз и плясок вокруг этого. У меня пока такое чувство, что это не решение проблемы, а костыли.

Ещё вопрос. Если пара файлов кочует из одного компонента в другой (читай - между неклонированными репозиториями), то их история сохраняется?

> Можно. Постом выше описал как это выглядит. Глянь.

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

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

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

Пример. Есть дерево исходников. В нем 3 каталога - a, b, c. Все это компоненты, что внутри каталогов - не важно. Лежит это дерево в ветке/репозитории (1). Где эта ветка - не важно, у нас распределенная система контроля версий, тут любая копия - это и ветка, и репозиторий одновременно, полностью самодостаточная сущность. Пусть это платформа (I). Хотим сделать новую версию, для новой платформы (II). Забираем исходники из (1) (darcs get), получая таким образом новую ветку/репозиторий (2). Для новой платформы нужны компоненты (a) и (b), но не нужен (c). Можем удалить в новой ветке каталог c. А можем не удалять. Также нужен новый компонент - (d). Создаем каталог d и его содержимое. Делаем патч, добавляющий этот каталог и его содержимое (darcs add, darcs record). Потом работаем над нашей новой версией, меняем компонент (a). Фиксируем работу в виде патчей в (2) (darcs record). Решили, что изменения в компоненте (a) - стабильны для платформы (II). Хотим их перенести в версию для предыдущей платформы (I), стабильные исходники которой в ветке (1). Нет проблем - делаем нестабильную ветку (3), копируя исходники из (1) (darcs get). Теперь вливаем изменения, касающиеся компонента (a) из (2) в (3) (darcs push или darcs pull по метке [a]). Если патчи, меняющие компонент (a), не трогали другие файлы, то в (3) изменится только содержимое каталога a. Если, предположим, какие-то изменения в компоненте (a) затрагивали и компонент (d), а политика фиксации изменений такова, что это были единые патчи (т.е. какие-то патчи меняли и каталог a, и каталог d), тогда darcs push/darcs pull вольет в (3) еще и каталог d. Теперь смотрим (3). Тестируем, правим, если что-то отвалилось. Фиксируем изменения (darcs record). Когда решаем, что модификация компонента (a) стала стабильной для платформы (I), то вливаем все изменения из (3) в (1) (darcs push или darcs pull). Все, ветка (3) больше не нужна, ее удаляем. Теперь, если при обеспечении стабильности (a) для платформы (I) мы его поменяли, то вливаем изменения этого компонента в (2) (darcs push или darcs pull по метке [a]). Поскольку процесс стабилизации общего кода для разных платформ в общем случае итеративный, то можем использовать еще одну промежуточную ветку для перенесения изменений из (1) в (2). Также можем использовать метки (tag), для фиксации стабильных срезов веток.

Я приводил команды для darcs, но для других DVCS все аналогично. В принципе, главное, что нужно уяснить при знакомстве с DVCS после SVN и прочих централизованных систем - в DVCS каждая копия - это и ветка, и репозиторий, полностью самодостаточный. Модель разработки с использованием DVCS предполагает активное порождение веток для всяких промежуточных действий. Порождать их может один разработчик на своей машине, давать к некоторым из них доступ для других разработчиков или распространять изменения из них в ветки на машинах других разработчиков (или централизованных, общих машинах) и т.д. То есть думать о репозитории в единственном числе тут нельзя.