При работе с Eclipse я должен добавить рабочую область к управлению исходным кодом?
Можно создать массив с набором размера к переменной, т.е.
int size = 50;
string[] words = new string[size]; // contains 50 strings
Однако, что размер не может измениться позже, если Вы решаете необходимость в 100 словах. При необходимости в размере, чтобы быть действительно динамичными, необходимо будет использовать другой вид структуры данных. Попробуйте List .
6 ответов
Я бы не добавил всю рабочую область, но я бы добавил .classpath и . файлы проекта (а также, разумеется, исходный код), чтобы при необходимости можно было воссоздать проект.
Я бы не стал фиксировать всю рабочую область. Но стоит экспортировать настройки платформы и проверить их в системе управления версиями (возможно, в отдельном проекте SCM, поскольку они на самом деле не относятся ни к какому отдельному проекту), если вы внесли несколько изменений на случай, если вам нужно импортировать их в новую рабочую область. .
Примерами этих файлов являются следующие настройки:
- Java-> Стиль кода-> Форматирование
- Java-> Стиль кода-> Очистить
- Java-> Стиль кода-> Шаблоны кода
- ] Общие-> Редакторы-Текстовые редакторы-Орфография-Словарь
- Любые другие настройки, в которые вы внесли значительные изменения, которые поддерживают импорт / экспорт
Вы должны проверить первичные источники / ресурсы для проекта. Как отмечали другие, для типичного проекта это включает файлы .project и .classpath.
В зависимости от типа проекта, я бы добавил из проекта папку .settings. Эта папка содержит параметры для конкретного проекта, которые переопределяют параметры платформы и другие параметры для конкретного проекта. Если они необходимы для вашего проекта, я бы добавил их.
Нет.
Файлы, созданные IDE или процессом сборки (двоичные файлы, документация, созданная генератором), не должны проверяться в системе управления версиями. Единственные файлы, которые должны быть возвращены, - это ваши исходные файлы и внешние библиотеки, которые используются вашими исходными файлами.
Возможно, вас также заинтересуют ответы на этот вопрос: Что НЕ должно находиться в системе контроля версий?
Даже если вы единственный разработчик, избегайте фиксации каталога .settings. Вы можете переключиться на другую версию Eclipse или другую установку с другим набором плагинов, и при проверке проектов во второй установке каталог .settings будет другим. Кроме того, каталог .metadata может меняться.
Тем не менее, попытайтесь использовать Maven, чтобы файлы Eclipse .project и .classpath могли быть сгенерированы без необходимости их регистрации.
Я бы зафиксировал только те проекты, над которыми вы работаете, а также файлы .classpath и .project, а не всю рабочую область.
Я играл с идеей (с Subversion) иметь "MyProject_Eclipseproj" папка, которая содержит только файлы и каталоги проекта Eclipse, с опорой svn: externals, которая извлекает все файлы / каталоги "MyProject".
Таким образом, макет будет следующим:
/repos/trunk/MyProject
/repos/trunk/MyProject/build.xml
/repos/trunk/MyProject/src
/repos/trunk/MyProject/src/com
/repos/trunk/MyProject/src/com/mypackage
/repos/trunk/MyProject/src/com/mypackage/MyClass.java
/repos/trunk/MyProject_Eclipse_34 <- external prop goes here
/repos/trunk/MyProject_Eclipse_34/.settings/
/repos/trunk/MyProject_Eclipse_34/.project
/repos/trunk/MyProject_Eclipse_34/.classpath
/repos/trunk/MyProject_Eclipse_35 <- external prop goes here
/repos/trunk/MyProject_Eclipse_35/.settings/
/repos/trunk/MyProject_Eclipse_35/.project
/repos/trunk/MyProject_Eclipse_35/.classpath
Папка MyProject будет чистым кодом , нет защиты от затмения. MyProject_Eclipse_Ver будет содержать файлы, специфичные для Eclipse, и указатели для извлечения папок с кодом. У вас также могут быть определенные папки для разных версий Eclipse, чтобы каждый разработчик не был вынужден обновляться, если что-то изменилось в файле .settings или .project между версиями.