Доброго дня.

Подскажите, как лучше всего разруливать следующую ситуацию.

Допустим, есть проект, находящийся под контролем системы управления версиями.
Разработчики заводят себе новые ветки для работы над новым функционалом,
затем время от времени синхронизируют свои изменения с центральным репозиторием.
Сам механизм ветвления и слияния в контексте рассматриваемого вопроса не особо важен.
Это может быть как create/reintegrate branch (SVN), так и pull/push (DVCS).

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

Например, Visual Studio хранит список файлов проекта в файле .vc(x)proj.
Когда две ветки с новыми файлами вливаются в центральный репозиторий, в этом
списке появляются конфликтные строки, которые приходится нудно (иногда очень нудно)
разрешать вручную всякими diff-тулами.

Вот фрагмент файла проекта (VS2010) в его первоначальном состоянии:

>243    <ItemGroup>
>244    <ClCompile Include="base.h"/>
>245    </ItemGroup>

Разработчик A в своей ветке добавил в проект файл feature-A.h и теперь вносит сделанные
изменения в репозиторий, строка 245:

>243    <ItemGroup>
>244    <ClCompile Include="base.h"/>
>245    <ClCompile Include="feature-A.h"/>
>246    </ItemGroup>

Разработчик B в своей ветке тоже создал новый файл проекта — feature-B.h и тоже
пытается занести изменения в репозиторий, получая при этом конфликт в строке 245:

>243    <ItemGroup>
>244    <ClCompile Include="base.h"/>

>------------ CONFLICT

>245    <ClCompile Include="feature-A.h"/>
>245    <ClCompile Include="feature-B.h"/>

>------------ END CONFLICT

>246    </ItemGroup>

Запрещать добавлять файлы в проект слишком бредово, это ж feature branches, они для того и придуманы.
Запрещать двум и более разработчиками делать ветки от одного проекта еще бредовее.
Исправлять конфликты вручную можно, но это неудобно (когда файлов несколько десятков), а еще этот
процесс подвержен ошибкам. Еще можно извратиться, и сливать изменения, сделанные в ветках, игнорируя
изменения файла проекта, а потом добавить новые файлы вручную, уже находясь в trunk, но это коряво.

Как быть ?

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

O>пытается занести изменения в репозиторий, получая при этом конфликт в строке 245:
O>

>>243    <ItemGroup>
>>244    <ClCompile Include="base.h"/>

>>------------ CONFLICT

>>245    <ClCompile Include="feature-A.h"/>
>>245    <ClCompile Include="feature-B.h"/>

>>------------ END CONFLICT

>>246    </ItemGroup>
O>

O>Как быть ?
Терпеть. Или не хранить vc(x)proj в репозитории. Или не использовать VS вообще.

ЗЫЖ Какая еще IDE требует поименно файлы перечислить в своих конфигах?

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

O>Доброго дня.
Доброго.

O>Как быть ?
1) Мержить руками. Такие вещи мержаться даже без привлечения головного мозга. Сложнее мержить ситуации когда оба еще что-то удалили и/или изменили в этом куске.
2) Переодически синхронизировать ветки -- уменьшишь вероятность возникновения таких ситуаций.

O>Еще можно извратиться, и сливать изменения, сделанные в ветках, игнорируя
O>изменения файла проекта, а потом добавить новые файлы вручную, уже находясь в trunk, но это коряво.
Вполне себе вариант -- мне нравится. Как раз успешность разрешения конфликтов в проектных файлах проверяется легко: собралось -- значит все верно. Хуже когда в коде конфликты. А еще хуже, когда конфликты в коде сгенеренном дизайнером.

GIV>ЗЫЖ Какая еще IDE требует поименно файлы перечислить в своих конфигах?
На вкус и цвет... Мне вот такой подход импонирует

СУВ, Aikin

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

A>2) Переодически синхронизировать ветки -- уменьшишь вероятность возникновения таких ситуаций.

Вот здесь непонятно. Ведь частота синхронизаций веток с транком никак не повлияет на
количество проблемных ситуаций, потому что файлы в обеих ветках все равно будут добавляться и
конфликты неминуемо возникнут, даже если делать commit и push на каждый "чих".

Ну и сама идея синхронизировать "подозрительную" ветку с "чистым и выглаженным" транком до
полного завершения работы в ней как-то не очень привлекает. Или я не понимаю смысла слова stable.

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


GIV>>ЗЫЖ Какая еще IDE требует поименно файлы перечислить в своих конфигах?
A>На вкус и цвет... Мне вот такой подход импонирует

Чем, если не секрет? Я работал и с VS и с не-VS — отсутствие этой фичи нисколько не напрягало а наличие приводило к сабжу.

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

A>>2) Переодически синхронизировать ветки -- уменьшишь вероятность возникновения таких ситуаций.

O>Вот здесь непонятно. Ведь частота синхронизаций веток с транком никак не повлияет на
O>количество проблемных ситуаций, потому что файлы в обеих ветках все равно будут добавляться и
O>конфликты неминуемо возникнут, даже если делать commit и push на каждый "чих".
Ключевое слово -- "уменьшить вероятность". Даже в случае единственной ветки и двух разработчиков могут появляться конфликты.


O>Ну и сама идея синхронизировать "подозрительную" ветку с "чистым и выглаженным" транком до
O>полного завершения работы в ней как-то не очень привлекает.
Я имею ввиду периодически забирать изменения из транка и мержить на "подозрительную" ветку.

O>Или я не понимаю смысла слова stable.
У каждого своя философия работы с ветками. У меня к транку только два требования: должен компилироваться и по возможности не падать. Для стабильного и чистого кода есть релизные ветки.

СУВ, Aikin

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

GIV>>>ЗЫЖ Какая еще IDE требует поименно файлы перечислить в своих конфигах?
A>>На вкус и цвет... Мне вот такой подход импонирует

GIV>Чем, если не секрет? Я работал и с VS и с не-VS — отсутствие этой фичи нисколько не напрягало а наличие приводило к сабжу.
А хрен его знает Чувство контроля, что-ли. Хотя в эклипсе оствутствие такой фичи нисколько не напрягало.

СУВ, Aikin