Использование Solution Explorer против использования Source Control Explorer при работе с TFS

#visual-studio #visual-studio-2010 #version-control #tfs

#visual-studio #visual-studio-2010 #контроль версий #tfs

Вопрос:

Пытаясь использовать TFS 2010, я запутался с тем, какую опцию использовать при работе с локальными копиями файлов в Visual Studio 2010: Solution Explorer или Source control Explorer.

Обозреватель решений — более естественный способ сделать это (по крайней мере, для начинающих, таких как я), но использование Source Control Explorer кажется более удобным и продуктивным. Доступно больше опций, но при нажатии на файл вы все равно открываете его локальную копию.

В чем преимущества использования одного подхода по сравнению с другим?
Должен ли я по-прежнему использовать File => Open => Project / Solution или мне лучше использовать Team Explorer => Source Control (это кажется еще быстрее)?
В каких ситуациях использование Solution Explorer, очевидно, является лучшим (или даже единственным) вариантом?

Ответ №1:

Обозреватель решений предназначен для работы с решением, то есть для разработки. Когда вы открываете файл из Solution Explorer, вы открываете часть своего проекта — VS учитывает, какие сборки, пространства имен и т. Д. Должны Быть видны из этого файла, Что дает вам intellisense. Кроме того, контекстные меню в Solution Explorer предназначены для процесса разработки — обратите внимание на все эти «Build», «Rebuild», «Set as start up project» и так далее.

Когда вы просматриваете свое решение в Solution Explorer, вы видите только те части, которые используются в исходном коде, я имею в виду скомпилированные файлы, ресурсы и т.д. Более того, может возникнуть ситуация, когда у вас будет файл, включенный в решение, но не включенный в систему управления версиями, и единственное место, где его можно увидеть, — в Solution Explorer.

С другой стороны, Source Control Explorer предназначен для работы с системой управления версиями. Это позволяет добавлять и удалять файлы в репозитории, проверять и извлекать, обновлять и т. Д. Это не имеет никакого отношения непосредственно к процессу разработки — например, Source Control Explorer не даст вам возможности что-либо скомпилировать. Открытие файла в Source control Explorer открывает его как отдельный файл — да, он по-прежнему доступен для редактирования, но теперь он не зависит от контекста, не дает вам intellisense и так далее.

При просмотре исходных текстов в обозревателе управления версиями вы не ограничены отдельным решением. Представьте ситуацию, когда у вас также есть папка с документами проекта (спецификации, макеты) в системе управления версиями. Возможно, вы не хотите включать их в свое решение, но вам все равно нужно как-то управлять ими — обновлять их версии в системе управления версиями, добавлять новые и так далее. Это невозможно, пока вы находитесь в обозревателе решений, поскольку вы не можете видеть ничего, кроме самого решения. Поэтому единственным местом, где вы можете работать с этими файлами, является Source Control Explorer.

Подводя итог, Solution Explorer предназначен для работы с исходным кодом, то есть для разработки, Source Control Explorer предназначен для работы с репозиторием.

Ответ №2:

Обозреватель решений обычно используется, когда вы выполняете какую-то работу локально. Вы проверите свой файл, внесете любые изменения, которые захотите, и проверите файл. Но получение последней версии из Solution explore иногда может быть сложным. Предпочтительно использовать Source Control Explorer для получения последней версии файлов. Итак, в моем случае первое, что я сделаю в начале дня, — это использую source Control Explorer для получения последних файлов, а затем использую Solution Explorer в течение дня для взаимодействия с TFS.

Комментарии:

1. «Но получение последней версии из Solution explore иногда может быть сложным. Предпочтительно использовать Source Control Explorer для получения последней версии файлов» можете ли вы уточнить?

2. Я работаю над проектом, в котором несколько файлов проекта используются совместно между 2 различными решениями Visual Studio. Когда я беру последнюю версию из Solution Explorer, иногда не все связанные файлы заменяются последней версией. Но получение последней версии из source Control Explorer гарантирует мне все последние файлы. Я надеюсь, что это отвечает на твой вопрос, mbx.

3. Это так, но вызывает еще один вопрос 🙂 Как вы управляете процессом сборки / тестирования? Если вы регистрируете изменения в одном из этих общих проектов в контексте одного решения, вам необходимо запустить тесты для всех других затронутых решений.

4. Да, из-за этого процесс сборки был в беспорядке. Но теперь мы используем Jenkins для непрерывной интеграции. Для нас это сработало волшебно. При каждом возврате он инициирует сборку и возвращается, если в каком-либо решении произошел сбой сборки. Таким образом, время на поиск проблемы у нас теперь составляет всего 20 минут.