Контроль версий для одного проекта с использованием eclipse?

В настоящее время я работаю над несколькими проектами самостоятельно (по крайней мере, часть разработки выполняется только мной:). Используя Eclipse с различными Java, R, SQL и другими исходными файлами, мне интересно, какая система контроля версий будет лучше для меня.

В то время история Eclipse IDE кажется достаточной, но я не уверен, будет ли это правдой в месяц/год...

Какое решение вы бы порекомендовали и почему?

Чтобы быть более точным: я уверен, что буду использовать SVN или git, если я решит использовать полную систему управления версиями. Но я просто не уверен, что это необходимо...

small update: has the release of Eclipse Helios added new opinions?

Ответ 2

Я бы рекомендовал практически любую из распределенных систем управления версиями. Я использовал git и hg в гневе и ткнул в fossil (я включаю его, потому что он предлагает некоторые функции, которые отсутствуют git и hg). Я сломаю основные плюсы и минусы в моих глазах (ПРИМЕЧАНИЕ: если у всех они есть то же преимущество, я не буду упоминать об этом, например, все они быстрые и легкие):

  • git
    • Pros
      • Очень гибкий
      • GitHub
    • Cons
      • Крутая кривая обучения
      • Более гибкий
      • Интеграция Eclipse была хромой в последний раз, когда я смотрел
  • hg
    • Pros
      • (IMO) более согласованные команды
      • Менее гибкий
      • BitBucket
    • Cons
      • Менее гибкий
      • Не так много, как git
    • Предостережения
      • Я не проверял поддержку Eclipse в последнее время; он был лучше, чем git, но казался довольно застойным.
  • fossil (отказ от ответственности: я не использовал это в гневе)
    • Pros
      • Написано человеком, стоящим за SQLite, поэтому вы можете быть уверены, что он SOLID code
      • Обеспечивает больше, чем просто контроль версий, например, распределенный отладчик ошибок
      • Легко настроить для доступа других пользователей
    • Cons
      • Не так много импульсов, как git или hg
      • Я уверен, что интеграция Eclipse для fossil не существует (это был последний раз, когда я смотрел)
      • Нет бесплатного хостинга, который я знаю о параллельном GitHub или BitBucket, поэтому вам действительно нужно разместить свое репо.

Существуют и другие DVCS, в том числе darcs и bzr, но я не использовал их достаточно, чтобы иметь достойное мнение о них.

Ответ 3

Git, потому что вы можете сразу начать и не нуждаться в сервере центрального репозитория.

Некоторые другие преимущества (по сравнению с другими SCM):

  • Меньшая загроможденная файловая система: Git создает только папку в корне репозитория (в отличие от SVN).
  • Не мешает так "нормальным" функциям обработки файлов. Например. в SVN вам нужно использовать пользовательские команды для переименования или перемещения файлов. Это не относится к Git.

У меня ощущение, что Git очень легкий, поэтому нет причин ждать, пока ваш проект "достаточно большой" или что-то еще.

Ответ 4

Насколько я понимаю, речь идет только о том, какую систему управления версиями вы предпочитаете больше всего.

Но самая эффективная система, вероятно, git Я думаю. http://www.eclipse.org/egit/ для плагина eclipse:)

Я бы рекомендовал использовать систему управления версиями в любом случае. Даже в небольших проектах вы придете очень быстро до такой степени, что предыдущее решение, возможно, было бы лучше. Без системы контроля версий вы будете выполнять жесткие изменения или вернуться к предыдущим версиям (ну, это одно из больших преимуществ этих систем, верно?)).

Ответ 5

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

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

Ответ 6

Git и Mercurial (hg) действительно имеют большой импульс в качестве распределенных репозиториев исходного кода, но, на мой взгляд, для группы из одного человека вы найдете наибольшую поддержку с Subversion. Если вы находитесь в Windows, то интеграция оболочки TortoiseSVN, которая является фантастической (она даже интегрируется с Trac) и бесплатным хостингом Subversion, повсюду и имеет личный опыт работы с ProjectLocker.com(они делают Git и SVN). Кроме того, Subversion довольно просто интегрируется непосредственно в среду Eclipse.

Ответ 7

Существует много преимуществ использования SCM вместо Eclipse histoiry даже для одного человека:

  • комментарии о коммитах: вы можете сказать, ПОЧЕМУ вы что-то сделали. Это поможет вам, когда вам нужно выяснить, почему какой-то код работает так, как он, основываясь на его истории.

  • резервные копии: О, вы полностью испортили рабочее пространство Eclipse? Просто создайте новую и запишите новую копию кода.

  • непрерывная интеграция: проверьте, что код строит после каждого сохранения, запускает тесты (это важно) и создает фактический двоичный код для отправки клиенту.

Это ваша сеть безопасности. Потратьте время, чтобы изучить его, и использовать его правильно. Вам это понравится:)