Маленький проект (два человека), постоянные конфликты .csproj при svn update — достаточно, чтобы оба добавили по файлу в проект.

Свежие тортойз + анк (сервер — Visual SVN), проблемы от используемого клиента не зависят (очевидно, на всякий уточняю).

Это by design, или можно как-то бороться?

Здравствуйте, Sinix, Вы писали:
S>Это by design, или можно как-то бороться?
Надо смотреть на характер конфликта. Простое добавление строк в разные части файла не должно быть конфликтным.
Если добавление идет примерно в одно и то же место и разрешение заключается в выборе порядка следования новых строк — это нормально.
Еще бывает, если студия, помимо собственно добавления строки о файле, меняет что-то еще на свое усмотрение в файле проекта — тут уж к самой студии вопросы.

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

MC>Если добавление идет примерно в одно и то же место и разрешение заключается в выборе порядка следования новых строк — это нормально.
Одна из проблем — точно. Другие точно не воспроизводил. А можно навесить какой-нить хук на обновление?

Здравствуйте, Sinix, Вы писали:
S>А можно навесить какой-нить хук на обновление?
Емнип, нет. А зачем? Автоматом разрешать конфликт какой-нибудь внешней разрешалкой?

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

MC>Емнип, нет. А зачем? Автоматом разрешать конфликт какой-нибудь внешней разрешалкой?
До хоть своё написать: две трети проблем — записи о добавленных файлах оказываются на одной и той же строчке. В тортойзе кстати свои хуки есть, но мы-то используем в основном анк. Пошёл им жаловаться

И ведь пока делили ответственность по проектам — никаких граблей. Интересно, как в больших коллективах такое разруливается?

Здравствуйте, Sinix, Вы писали:
S>До хоть своё написать: две трети проблем — записи о добавленных файлах оказываются на одной и той же строчке.
Ну так это ж всего пара кликов в мерже. Меня обычно не напрягает. Но вообще с свн надо быть очень аккуратным, когда в проекте часто удаляются/перемещаются файлы. Конфликты между ними и изменением — самые неприятные.

S>Интересно, как в больших коллективах такое разруливается?
У нас коллектив был не то, чтоб большой, но на такие вещи не обращали внимания. Кто апдейтился — просто разрешал конфликт — и все.

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

MC>Ну так это ж всего пара кликов в мерже.
И так для каждого файлика. По разу на дню минимум.
Кстати, что для мержа используете? У нас сейчас Tortoise Merge, но либо я его ещё не научился готовить, либо по юзабилити у него — твёрдый нуль.

MC>Но вообще с свн надо быть очень аккуратным, когда в проекте часто удаляются/перемещаются файлы. Конфликты между ними и изменением — самые неприятные.
Вот это постоянное ожидание граблей дико напрягает. Была хорошая идея — замороженный код помечать как needs-lock. После двукратного повреждения репозитария отказались. Как и от нанокоммитов и веток-на-фичу. Неюзабельно абсолютно.

Привык я к хорошему

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

S>Кстати, что для мержа используете? У нас сейчас Tortoise Merge, но либо я его ещё не научился готовить, либо по юзабилити у него — твёрдый нуль.

Araxis merge. Дорогой правда, но нам на работе купили, я очень доволен.

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

K>Araxis merge. Дорогой правда, но нам на работе купили, я очень доволен.
Да там Merging button есть! Буржуи

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

S>И так для каждого файлика. По разу на дню минимум.

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

S>Кстати, что для мержа используете? У нас сейчас Tortoise Merge, но либо я его ещё не научился готовить, либо по юзабилити у него — твёрдый нуль.

Попробуй winmerge

Здравствуйте, Sinix, Вы писали:
S>И так для каждого файлика.
Каждого — это какого? Вы там что-ли весь проект равномерно параллельно колбасите? Или речь только о csproj?
Кстати, возможно у вас слишком большие коммиты (раз в день — небось перед уходом). Можно пробовать выделять в работе отдельные таски и коммитить их по отдельности.

S>Кстати, что для мержа используете? У нас сейчас Tortoise Merge, но либо я его ещё не научился готовить, либо по юзабилити у него — твёрдый нуль.
Я его и юзаю. Видимо, привыкнуть надо. На мой взгляд, он очень правильно сделан, сразу видно что в файлах произошло и почему они конфликтуют.

Как и от нанокоммитов и веток-на-фичу. Неюзабельно абсолютно.
Пока не научились готовить в условиях своих проектов?

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

L>Если есть возможность, разбейте проект на несколько более мелких, "проблема" подуменьшится.
Проекты и так мелкие. До недавнего времени проблем не было. Как вдвоём занялись проектом-прототипом с бешеной генерацией кода на выброс — туши свет.

L>А вообще, на вашем месте я бы не обращал на это внимания, такого рода мерж не занимает много времени.
Увы-увы. Полез жаловаться после того, как нечаянно убрал из проекта файлы товарища.

L>Попробуй winmerge
С него и ушли. Надо будет сесть да определиться. Может, чего платного подойдёт...
Очень приглянулась бэта CodeCompare. Если починят баги в детекте конфликтов — вообще прелесть будет.

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

S>Это by design, или можно как-то бороться?

можно перейти на кросплатформенную систему сборки(cmake, boost bjam и пр.), в которой скрипты сборки прописываются человеком — ручками, тогда проблем с мержем автогенерённого текста не будет.

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

MC>Каждого — это какого? Вы там что-ли весь проект равномерно параллельно колбасите? Или речь только о csproj?
Только о csproj. Конфликтов просто несколько обычно. Проект-прототип, код активно тасуется туда-сюда по файликам. Хорошо хоть по фичам не пересекаемся (иначе вообще кошмар был бы).

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

MC> Можно пробовать выделять в работе отдельные таски и коммитить их по отдельности.
Примерно так и есть. Один фиг — файл проекта общий.

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

MC> Пока не научились готовить в условиях своих проектов?
Угу.

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

S>можно перейти на кросплатформенную систему сборки
От конфликтов на клиенте никак не спасёт.

S>(cmake, boost bjam и пр.), в которой скрипты сборки прописываются человеком — ручками, тогда проблем с мержем автогенерённого текста не будет.
Не согласен. С файлами от дизайнеров (как с самим описанием, так и с сгенеренным кодом) — больше всего проблем.

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

L>>Если есть возможность, разбейте проект на несколько более мелких, "проблема" подуменьшится.
S>Проекты и так мелкие. До недавнего времени проблем не было. Как вдвоём занялись проектом-прототипом с бешеной генерацией кода на выброс — туши свет.

Тогда как вариант: понадобилось добавить файл — гераешь последюю версию, добавляешь пустой, коммитишь. Но так неудобно.

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

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


S>>(cmake, boost bjam и пр.), в которой скрипты сборки прописываются человеком — ручками, тогда проблем с мержем автогенерённого текста не будет.
S>Не согласен. С файлами от дизайнеров (как с самим описанием, так и с сгенеренным кодом) — больше всего проблем.

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

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

S>я имел ввиду, что сгенерённого текста не должно быть в репозитории
И самого файла проекта в том числе?

S>а лежать скрипты — которые правятся ручками, на основании которых генерируется автогенерённый текст.
Их тоже мержить проблемно. Особенно XML-based файлы. Шило на мыло.

На всякий — в репозитарии всё прекрасно. Проблемы — в постоянных конфликтах.

Здравствуйте, Sinix, Вы писали:
S>код активно тасуется туда-сюда по файликам.
Да, в этом случае svn не особо удобен, замечал.

Здравствуйте, Mr.Cat, Вы писали:
MC>Да, в этом случае svn не особо удобен, замечал.
Интересно, в каких vcs с этим удобнее.