Зачем связывать версию управляющего плагина с IDE?

Интеграция IDE с контролем версий и, в частности, с управлением изменениями программного обеспечения (SCM) помогает вместе философии IDE и системы управления исходным кодом.

Одним из примеров являются временные файлы и двоичные файлы, которые не следует регистрировать и, например. в Visual Studio, в конечном итоге в исходном каталоге, если вы не тщательно создаете новые шаблоны проектов и решений с конфигурацией каталога, отличной от используемой по умолчанию.

Другим может быть отслеживание рабочих элементов и сложных исправлений ошибок.

Также это избавляет от некоторых церемоний и переключения контекста при редактировании файлов.

Расширенные интеграции могут также позволить внедрить концепцию конфигурации системы управления изменениями (ветвь, тег, представление) в IDE.

Однако интеграция с ClearCase явно не продвинута.

Интегрированный контроль версий также помогает держать под контролем только важные файлы. Например, когда я добавляю новый файл в Visual Studio, подключаемый модуль (visualSVN) позволит мне легко добавить его, и мне не нужно помнить, что нужно выходить за пределы моей IDE и запускать команду, чтобы добавить его в репозиторий. С другой стороны, он автоматически игнорирует временные файлы, такие как папки obj/ и bin/.

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

Мне нравится, как это реализовано в некоторых IDE. Ankh-SVN для Visual Studio не так хорош и немного глючит, однако Subeclipse Я считаю, что Eclipse работает очень хорошо.

Я думаю, что это действительно зависит от используемой вами IDE и качества этого плагина. Это будет хорошо работать для одних настроек и ужасно для других.

Вот почему мне так нравится Subversion с Tortoise SVN. Я могу использовать интеграцию IDE, когда и где это имеет смысл, в противном случае, как вы сказали, я могу просто использовать командную строку или, в моем случае, клиент на основе проводника Windows!

Во многом это просто предпочтения и уровень комфорта пользователя. Некоторым людям удобно работать с командной строкой. Некоторые предпочитают графический интерфейс.

Я бы не стал делать обобщенных предположений о том, что весь контроль версий в среде IDE плох или содержит ошибки, основываясь на опыте работы с конкретным подключаемым модулем, у которого были проблемы.

Зачем вообще нужна IDE? Почему бы просто не сделать все с помощью командной строки? ;)

Ответ заключается в том, что его интеграция с IDE «лучше».

Моя причина № 1: вы можете визуально увидеть, извлечен файл или нет, и если вам нужно отредактировать файл, вы можете предпринять действие прямо там, где вы работаете.

Есть еще, но это большой.

Это зависит от вашей IDE и того, как вы работаете с VCS.

Я и моя команда используем подключаемые модули VSS внутри Delphi IDE, это дает много гибких функций при совместной работе, например, все наши формы регистрируются, когда вы начинаете писать письмо или перемещать компоненты, они спросили, хотите ли вы проверить -из файла кода или формы.

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

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

Я считаю, что большинство людей, которым нравится иметь дело с командной строкой, работают в основном в коде без GUI IDE, или я могу ошибаться.

Почти все мои потребности в подрывной деятельности могут быть обработаны интерфейсом IDE. Гораздо быстрее сделать 2 быстрых щелчка, чем открыть командную строку, перейти в нужное место, ввести команду и т. д.

Командная строка имеет свое место, но с нынешним урожаем IDE это место продолжает сокращаться.

У меня есть боевые шрамы от использования ошибочной реализации интеграции IDE/VCS. Честно говоря, если бы не глючило, было бы здорово. Пока есть такие замечательные инструменты, как TortoiseSVN, я не вижу необходимости в интеграции IDE/VCS. Я бы предпочел иметь больше инструментов, которые хорошо выполняют свою работу, чем несколько глючных инструментов.

Поддержка управления версиями в среде IDE, как правило, обеспечивает лучшее представление. Среда IDE фактически знает, какой тип файла вы просматриваете при выполнении сравнения, а это значит, что она может выполнять подсветку контекста и помогать вам выполнять слияния более эффективно.

Я также думаю, что это экономит время установки. Вместо того, чтобы устанавливать всевозможные инструменты, разработчик может загрузить IDE, проверить ее и начать работу. Если каждый разработчик проекта использует одну и ту же IDE, они могут помогать друг другу.

«Контрпродуктивно» — громко сказано. Если у вас возникают серьезные проблемы с CVS/SVN, может быть, раз в месяц, все равно мало кто будет устанавливать сложные клиенты на всех ваших машинах разработки.

У меня есть обе системы, где есть интегрированная среда разработки (Microsoft FrontPage на веб-сайте разработки IIS с Visual Source Safe для всего веб-контента) и где ее нет (разработка командной строки Java, Visual Studio Express Editions). Промежуточный случай, который я использую, — это jEdit 4.x с интеграцией VSS через плагин.

Я думаю, что интегрированный случай ценен по той причине, что он всегда таков: вам не нужно выходить из приложения, чтобы взаимодействовать с функциями управления исходным кодом, и вам не нужно беспокоиться о том, чтобы не забыть добавить новые файлы и извлечь файлы. перед их редактированием. Насколько я понимаю, способность обеспечить гладкий рабочий процесс и свести к минимуму риск недосмотра очень важна. Даже когда интеграция IDE-плагина не идеальна (случай jEdit 4.x), я все равно предпочитаю ее отсутствию.

Я также согласен с тем, что интеграция проводника в Windows, в случае с Tortoise SVN, также является отличной возможностью, даже если доступна интеграция с IDE. Это обеспечивает удобную работу без необходимости запуска среды IDE, а также возможность запуска из окна проводника в среду IDE (в зависимости от типа файла) или редактор, make или что-то еще во время работы в проводнике Windows.

И да, интерфейсы командной строки остаются ценными, особенно для написания сценариев повторяющихся операций.

Я работаю во многих контекстах. Низкие барьеры и плавность работы во всех из них следует ценить.

Я не уверен, что понимаю вопрос. IDE по определению являются интегрированными, а это означает, что они должны помочь вам избежать необходимости выходить из среды для чего-либо, связанного с проектом. Контроль версий, очевидно, отвечает всем требованиям.

Если вы ищете более практические причины, одна из них заключается в том, что IDE могут предложить вам осведомленность по характеру их графического представления. Eclipse, например, покажет измененные файлы и каталоги. С дополнительными плагинами или пакетами вы всегда можете получать информацию в режиме реального времени, как только другой пользователь редактирует тот же файл, помогая вам предсказать конфликт слияния до того, как он возникнет. Я не знаком с механизмом командной строки.

Я использую intellij, интегрированный с cvs, на регулярной основе, и, безусловно, лучшая функция интеграции контроля версий внутри IDE — это построчные указания того, что добавлено, отредактировано или удалено, а также легкий доступ (наведение мыши/инструмент подсказка) к предварительным изменениям.

Все это находится в исходном коде ненавязчивым образом.

Для управления версиями (checkin/checkout/update/etc) я иногда использую IDE, а иногда использую командную строку.

Причина номер 1 для SCM, интегрированного с IDE, заключается в том, что это упрощает его использование и устраняет необходимость ПОМНИТЬ, чтобы проверять вещи. По своему опыту я видел, что шаги, которые разработчики считают ненужными, которые часто включают в себя что-то еще, кроме написания кода, не выполняются. Заставляя их выполнять дополнительные действия, вы увеличиваете вероятность того, что разработчики не будут этим заморачиваться и будут обходить систему управления исходным кодом.