Установлена и работает SVN.
Ко мне тут подошли разработчики, и требуют странного:

Есть 2 каталога с проектом: каталог С (стабильный) и каталог Д (девелоперский).
В каталоге С иногда правятся мелкие ошибки, этот каталог в основном тестят тестеры,
на нем же постановщики придумывают свои постановки, с него же делаются релизы.

Каталог Д отличается нестабильностью и активной ежедневной колбаснёй.
Хотят периодически переливать баг-фиксы из ветки С в ветку Д,
а также периодически переливать выборочный пяток-десяток файликов из Д в С.

Говорят, нет такого способа — выборочный мерж. Сливает все файлы без вопросов.

Пока всё ручками делают (ну вернее через WinMerge), но похоже запарились они там.
Спрашивают — есть ли способ вести эти 2 каталога именно через SVN.
Готовы перейти на GIT или HG, если там есть нужный функционал.

Здравствуйте, Аноним, Вы писали:

А>Каталог Д отличается нестабильностью и активной ежедневной колбаснёй.
А>Хотят периодически переливать баг-фиксы из ветки С в ветку Д,
А>а также периодически переливать выборочный пяток-десяток файликов из Д в С.

Сам не пробовал, но по идее так:
В TortoiseSVN зайти в лог, в логе выбрать нужную ревизию с D-багфиксом, правой кнопкой "Merge revision to..." и указать стабильную ветку.

Можно попробовать еще в том же TortoiseSVN через Repo-browser сравнить две ветки и оттуда что-то делать.

В любом случае, мёрж руками идеологически неверен.

Здравствуйте, Аноним, Вы писали:
А>Каталог Д отличается нестабильностью и активной ежедневной колбаснёй.
А>Хотят периодически переливать баг-фиксы из ветки С в ветку Д,
Это обычный merge из С в Д.

А>а также периодически переливать выборочный пяток-десяток файликов из Д в С.
А вот это хуже. В svn не получается нормально мержить в обе стороны. Предполагается, что бранч Д в итоге будет реинтегрирован (merge --reintegrate) в С и удален.

А>Готовы перейти на GIT или HG, если там есть нужный функционал.
Тут можно будет нормально переносить любые коммиты как из С в Д, так и наоборот. Не файлы, а именно коммиты.

Здравствуйте, Аноним, Вы писали:

А>Каталог Д отличается нестабильностью и активной ежедневной колбаснёй.
А>Хотят периодически переливать баг-фиксы из ветки С в ветку Д,
А>а также периодически переливать выборочный пяток-десяток файликов из Д в С.
git. Это типичный use-case для git cherry-pick.

Здравствуйте, Cyberax, Вы писали:
C>git. Это типичный use-case для git cherry-pick.
Можно поподробнее про этот юзкейс? В чем суть?

Здравствуйте, Mr.Cat, Вы писали:

MC>Здравствуйте, Cyberax, Вы писали:
C>>git. Это типичный use-case для git cherry-pick.
MC>Можно поподробнее про этот юзкейс? В чем суть?
Необходимость портировать несколько коммитов из одной ветки в другую (из нестабильной в стабильную).

Здравствуйте, Cyberax, Вы писали:
C>Необходимость портировать несколько коммитов из одной ветки в другую (из нестабильной в стабильную).
Это я знаю. Просто ТС говорил про отдельные файлы. Т.е. cherry-pick может из коммита выдрать инфу только об определенном файле?

On 12/02/2010 18:51, Mr.Cat wrote:

> C>Необходимость портировать несколько коммитов из одной ветки в другую
> (из нестабильной в стабильную).
> Это я знаю. Просто ТС говорил про отдельные файлы. Т.е. cherry-pick
> может из коммита выдрать инфу только об определенном файле?
git позволяет редактировать коммиты. В этом случае я бы, скорее всего, сделал cherry-pick, потом rebase с нужными правками, потом push в центральный репо.