NetBeans и Java: что добавить к управлению версиями? - PullRequest
Новая
       26

NetBeans и Java: что добавить к управлению версиями?

9 голосов
/ 19 февраля 2010

Что мне нужно добавить помимо очевидного (src, dist) к моей системе управления версиями из каталога проекта Java NetBeans? Могу ли я удалить весь каталог сборки? Должен ли я добавить каталог nbproject, поскольку я работаю над тем же проектом на другом компьютере?

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

Ответы [ 5 ]

8 голосов
/ 19 февраля 2010

Примечание: этот ответ относится к NB 6.8 (который я сейчас использую) и, вероятно, также относится к большинству версий 6.x, которые, вероятно, будут в дикой природе.

Краткий ответ: используйте пункт меню «Импорт в репозиторий», чтобы выполнить первоначальную регистрацию. Среда IDE проверит то, что, по ее мнению, необходимо.

Это немного сложно найти. Выберите ваш проект в Project Explorer. Откройте меню «Команда» в строке меню. Как только вы нажмете на нее, вы увидите что-то вроде: 

Kenai>
------
CVS>
Mercurial>
Subversion>
______

Импорт в элемент является вложенным элементом CVS / Mergcurial / Subversion.

Если вы хотите выполнить регистрацию «вручную», вот список вещей, которые IDE обычно помещает в репозиторий:

  • src dir (и все вложенные файлы и папки)
  • test dir (и все вложенные файлы и папки)
  • nbproject dir (и все файлы и папки - за исключением «личная» папка и ее содержимое)
  • build.xml
  • manifest.mf
2 голосов
/ 19 февраля 2010

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

По сути, все, что вы не генерируете.

Исключениями могут быть зависимые банки. Включите ли вы их или нет, зависит от того, есть ли у вас общее расположение библиотеки, на которое могут ссылаться другие, или нет. По привычке у меня всегда были среды с общими местоположениями вместо того, чтобы контролировать его для каждого проекта (в конце концов, сколько раз вы хотите хранить log4j и все его версии под контролем исходного кода). Конечно, теперь мы используем для этого пользователя maven, чтобы об этой проблеме позаботились (см. Мой ответ, касающийся Maven и Eclipse в том же вопросе, связанном выше).

1 голос
/ 19 февраля 2010

Исходный код, файлы ресурсов (изображения, файлы конфигурации и т. Д.) И сценарии сборки (в Netbeans все файлы сборки ant) ​​должны находиться в хранилище.

Не помещайте туда каталог dist / build. Как правило, не рекомендуется помещать встроенные артефакты (файлы классов, файл проекта и т. Д.) В систему контроля версий.

Однако совместное использование метаданных Netbeans может быть полезно при работе над одним и тем же проектом с разных машин.

0 голосов
/ 19 февраля 2010

Все, что нужно для сборки и запуска проекта с нуля.

Не забудьте также добавить свой каталог lib.Я абсолютно НЕНАВИЖУ ЭТО, когда извлекаю информацию из системы контроля версий, и все зависимые файлы JAR не могут быть найдены, заставляя меня продолжать догадываться, пока я не разрешу все исключения ClassNotFound.Не добавляйте каталог сборки или сценарий сборки Netbeans, если вы не привязаны только к запуску Netbeans.Другой альтернативой является добавление сценария сборки (не Netbeans).

0 голосов
/ 19 февраля 2010

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

Agile практики также явно включают это. Помимо исходного кода и файлов проекта, рассмотрите возможность сборки, развертывания сценариев, схем и макетов базы данных, конфигураций, документации (!), Тестовых файлов, зависимых библиотек, задач, веб-сайта проекта ... Конечно, иногда трудно поместить, например, образ виртуальной машины в систему контроля версий (двоичную), для этого могут быть более подходящими обычные снимки. Но если вы когда-нибудь спросите себя, должен ли я поставить это под контроль версий, ответ почти всегда да, вам следует. (Следуя этой практике, вам также будет легче принимать решения о версиях.)

...