Маленький проект (два человека), постоянные конфликты .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 с этим удобнее.

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

MC>Интересно, в каких vcs с этим удобнее.
В даннов конкретном случае проблемы не в VSC, а в поддержке проектов со стороны анка (для тортойза всё-таки не профильная фича).

Здравствуйте, Sinix, Вы писали:
S>В даннов конкретном случае проблемы не в VSC, а в поддержке проектов со стороны анка (для тортойза всё-таки не профильная фича).
Ммм, а при чем тут анк? Он ведь только говорит за тебя "svn move", когда файл тягается по проекту. А конфликт, я так понял, у тебя именно в файле проекта, к которому анк отношения не имеет. Не?

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

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

разумеется, его быть не должно.

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

есть большой выбор нормальных систем, тотже cmake и bjam- никакие не xml-based'ы.

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

ага, о них и речь.

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

MC>Ммм, а при чем тут анк? Он ведь только говорит за тебя "svn move", когда файл тягается по проекту. А конфликт, я так понял, у тебя именно в файле проекта, к которому анк отношения не имеет. Не?

Так анк позиционируется как утилита интеграции SVN в студию, не? Вот и пусть интегрирует

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

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

git

Здравствуйте, kvasya, Вы писали:
K>git
Точно? Хотя, говорят, там алгоритм мержа поинтереснее — а у ТС как раз проблема в мерже сильно "нагруженных" правками файлов. С другой стороны, конфликты с добавлениями в одно и то же место вряд ли уйдут.
Ну и под винду я бы все-таки вместо git юзал hg.

Здравствуйте, Sni4ok, Вы писали:
S>есть большой выбор нормальных систем, тотже cmake и bjam- никакие не xml-based'ы.
Есть подозрение, что ТС интересует дотнет. Сабжи даже если умеют его — они непопулярны со всеми вытекающими.

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

MC>Здравствуйте, kvasya, Вы писали:
K>>git
MC>Точно? Хотя, говорят, там алгоритм мержа поинтереснее — а у ТС как раз проблема в мерже сильно "нагруженных" правками файлов. С другой стороны, конфликты с добавлениями в одно и то же место вряд ли уйдут.
Конфликты бывают разумеется. Я говорил про "перемещения". У git это легко т.к. вписывается в его концепцию "истории контента".

MC>Ну и под винду я бы все-таки вместо git юзал hg.
Я бы не Я уже полюбил git.

Здравствуйте, kvasya, Вы писали:
MC>>Ну и под винду я бы все-таки вместо git юзал hg.
K>Я бы не Я уже полюбил git.
Качество инструментов под винду нагоняет на меня тоску.

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

K>>Я бы не Я уже полюбил git.
MC> Качество инструментов под винду нагоняет на меня тоску.
А. Понятно Я в консоли (cygwin+console2) чаще работаю, поэтому не заметил.
Тем не менее, TortoiseGit вполне достойный инструмент. У меня еще не критично не ошибался ни разу. В ранних версиях с кодировкой не дружил, сейчас все Ok.
Кроме того, Git GUI. Несмотря на страшный вид, позволяет делать то, для чего предназначен. Где то был толковый вебкаст про него, но что-то найти не могу.

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

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

MC>>Ммм, а при чем тут анк? Он ведь только говорит за тебя "svn move", когда файл тягается по проекту. А конфликт, я так понял, у тебя именно в файле проекта, к которому анк отношения не имеет. Не?

S>Так анк позиционируется как утилита интеграции SVN в студию, не? Вот и пусть интегрирует

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

Здравствуйте, kvasya, Вы писали:
K>cygwin
И нормально работает (русские имена и комменты, ssh и т.п.)? Странно. А cygwin на vista/win7 до сих пор с плясками ставится?

K>TortoiseGit
В свое время не удалось подцепить из него msysgit — хотя тот вроде был установлен. Вроде — потому что недавно вот ставил голый msysgit — он наотрез отказался делать push.
В итоге остановился на git extensions (у которого внутрях какой-то свой msysgit), которые заработали со второй попытки (из git gui, их собственный гуй не дал сделать pull). Они, правда, недавно сломали инсталлер. И не все конфиги понимают (.netrc у меня не работает), но хоть с pull-commit-push все ок.

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

MC>Здравствуйте, kvasya, Вы писали:
K>>cygwin
MC>И нормально работает (русские имена и комменты, ssh и т.п.)?
Да. С наскоку "из коробки" работать, скорее всего, не будет. Но сразу быка за рога, utf-8 + настройка git.
Проблем с этим не было.

MC>А cygwin на vista/win7 до сих пор с плясками ставится?
Засада. Я отказался (в пользу PowerShell).

K>>TortoiseGit
MC>В свое время не удалось подцепить из него msysgit — хотя тот вроде был установлен. Вроде — потому что недавно вот ставил голый msysgit — он наотрез отказался делать push.
На заре TGit — он у меня тоже не поплыл (что-то было и с операциями и с кириллицей ). Но с какой-то версии он успешно встал и просто заработал.

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

S>Маленький проект (два человека), постоянные конфликты .csproj при svn update — достаточно, чтобы оба добавили по файлу в проект.
Попробуй другой diff tool.
Подробности: SVN diff: Как оградить себя от "ошибок" определения изменени

Автор: Aikin
Дата: 28.11.08

СУВ, Aikin

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

A>Попробуй другой diff tool.
Дык оно всё одинаково убогое

Автор: Sinix
Дата: 15.05.10

.

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

A>>Попробуй другой diff tool.
S>Дык оно всё одинаково убогое

Автор: Sinix
Дата: 15.05.10

.
И кто же победитель? Кто сейчас рулит твои мержи?

СУВ, Aikin

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

A>И кто же победитель?
Windiff (повторяю как дятел, самому надоело), но он не умеет мерж.

Поэтому использую Compare It! (это не эмоции, это оно так зовётся). Ещё из кандидатов — Compare++ и CodeCompare. Если их доделают до юзабельного состояния. За последний болею больше всех — идея правильная, реализация — посмотрим.

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

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

A>>И кто же победитель?
S>Windiff (повторяю как дятел, самому надоело), но он не умеет мерж.

S>Поэтому использую Compare It! (это не эмоции, это оно так зовётся). Ещё из кандидатов — Compare++ и CodeCompare. Если их доделают до юзабельного состояния. За последний болею больше всех — идея правильная, реализация — посмотрим.
Спасибо.


СУВ, Aikin

P.S. Победитель -- это тот, кто стоит у тебя на машине и рулит diff/merge.
Так что Windiff не победитель.

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

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

Если вы работаете вдвоем и не пересекаетесь по фичам, то значит работаете над разной функциональностью, и никто не мешает этот проект разбить на два по области вашей работы — даже если такое разбиение проекта не будет слишком логичным, все равно же "код на выброс".