Есть какие-нибудь советы по использованию Subversion с файлами проекта .net?
Мы только что перешли с TFS на SVN, и пока нам это нравится.
Однако при этом появилось несколько новых проблем.
Один из них - это способ обработки файлов проекта (в частности, .vbproj). Файл .vbproj, конечно, всегда меняется по мере изменения файлов и ссылок, и если несколько человек будут сотрудничать, возникнут конфликты.
Как ни странно, в TFS нам никогда не приходилось иметь дело с управлением этими конфликтами, эта конкретная часть обрабатывалась автоматически. Теперь в SVN мы просматриваем XML в инструменте слияния, и уже были некоторые ошибки.
Как ты с этим справишься? Какие-нибудь советы?
Обновлено:, кстати, мы используем VisualSVN.
Ответы 7
Эта конкретная проблема возникает, если несколько разработчиков добавляют файлы в один и тот же проект.
Чтобы разрешить конфликт, когда несколько разработчиков добавили файлы в один и тот же проект, вы обычно можете заставить его работать, разрешив его с помощью опции «мой, прежде чем их». Он добавит оба ваших изменения вместе.
Эта проблема и другие проблемы слияния решаются частым коммитом и обновлением. По возможности фиксируйте один раз в день или чаще. Чем дольше вы будете обходиться без обновлений и фиксации, тем больше боли вы и ваша команда почувствуете.
Вам нужен достойный клиент, такой как Toroise. Иногда возникают конфликты при автоматическом слиянии, но у ive никогда не было конфликтов с .vbproj, и их очень легко исправить с помощью программы diff.
id использует _svn вместо .svn, по нескольким причинам, я не могу вспомнить, почему сейчас не в моей голове, но "." причинил мне горе.
убедитесь, что вы не фиксируете файлы .user и .suo, иначе вы будете продолжать получать друг от друга настройки VS для проекта, что будет раздражать!
Вы также можете получить клиентские надстройки для VS, такие как ankh и visual svn, ive только немного использовал ankh, но это было немного медленно, но, вероятно, это была ошибка моего ПК.
_svn vs .svn - это совместимость с ASP.NET.
Если быть более точным, _svn требуется только при использовании Visual Studio .NET или Visual Studio .NET 2003, 2005 и более поздних версий.
В SVN основные проблемы с файлами * proj возникают, когда люди перемещают файлы в разные папки и / или когда они добавляют и удаляют файлы с одинаковыми именами одновременно, обычно в начале проекта.
Как только имена файлов и структура проекта станут более стабильными, этого больше не произойдет.
Кроме того, включайте только файлы .sln и .vbproj, не включайте постоянно меняющиеся файлы .suo, чтобы уменьшить головную боль.
Обычно мы обновляем * файл proj + добавляем или перемещаем заглушку файла + фиксируем все сразу. Сделайте операцию как можно более атомарной, а продолжительность - как можно короче.
Вы уверены, что файл вашего проекта не помечен как двоичный? Если ваш файл .vbproj имеет свойство svn: mime-type со значением, которое не начинается с 'text /', автоматическое слияние субверсий будет отключено.
Когда пару лет назад мы перешли с VSS, большинство файлов проекта были помечены как двоичные. Удаление свойств MIME-типа устраняет большинство конфликтных ситуаций.
Попробуйте VisualSVN. Он работает вместе с TortoiseSVN, чтобы управлять всем за вас и интегрировать функциональность Subversion с Visual Studio. Он также настраивает svn: ignore для пользовательских файлов проекта и двоичных файлов, чтобы сохранить их в репозитории. Стоит затраченных усилий.
Да, VisualSVN - это то, что вам нужно.
Мне тоже нравится VisualSVN (по крайней мере, до тех пор, пока я не переключился на Mercurial), но, как предлагает Майк С. в комментарии к моему ответу, это не ответ на заданный OP более конкретный вопрос относительно конфликтов слияния в проекте на основе .NET XML. файлы.
Попробуйте АнхСВН. Очень доволен версией 2. Изначально он игнорирует файлы .suo и т. д., Работает безупречно с VS 2008, и это бесплатно !!
Как это отвечает на заданный вопрос?
Хорошая точка зрения. Похоже, я ответил на вопрос заголовка, а не на тот, который встроен в тело. Последовал за ответом X-Cubed, как мотылек на пламя. Предположим, заголовок должен быть больше похож на «Какие-нибудь советы по разрешению конфликтов слияния проектов .NET с помощью инструментов на основе Subversion?»
Как насчет объединения веток? Здесь мы всегда чувствуем боль.