Что входит в контроль источника?

Ответ 1

Я обобщил все свои выводы в сообщении в блоге, которое можно найти здесь: http://www.aydabtudev.com/2011/05/what-goes-into-source-control-android.html

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

svn rm --keep-local .classpath
svn rm --keep-local .project
svn rm --keep-local default.properties
svn rm --keep-local proguard.cfg
svn rm --keep-local bin/
svn rm --keep-local gen/

Затем я выполнил следующую команду, чтобы добавить их в список игнорирования:

svn pe svn:ignore .

Добавьте каждый элемент выше без соответствующей команды:

.classpath
.project
bin/
...

Я следил за этим с фиксацией и обновлением, чтобы укрепить мои изменения.

svn commit -q -m "Removing files" .
svn update

Казалось бы, более разумным способом сделать это будет настройка Ignored Resources в настройках Team Eclipse.

Ответ 2

Если вы используете SVN, вы должны выборочно добавлять файлы/каталоги в свой репозиторий.

Например, со следующей структурой каталогов (быстрый пример с моего диска):

res/
src/
build/
.idea/

Вы хотите не создать каталог сборки, а также личные настройки для вашей папки IDE (.idea), поэтому вы должны выполнить только команду: svn add res src

Чтобы (я думаю) ответьте на второй вопрос, я бы сначала сделал все, что связано с управлением версиями из командной строки, а затем дайте вашей среде IDE сделать это.

Приношу свои извинения, если мне не хватает точки вопроса.

Ответ 3

Вот некоторые основные моменты:

• Не храните материал в управлении версиями, созданный исходным кодом. Например, если вы создаете jar файл, не храните этот jarfile под контролем источника.
• Контроль источника для источника. Если у вас есть релизы, используйте репозиторий выпуска, например Artifactory. Не позволяйте вещи Maven отпугивать вас. Возможно, вы не используете Maven (сейчас), но инструмент репозитория Maven находится в стандартном формате и позволяет легко находить ваши релизы. Artifactory может работать с Ant/Ivy, и с небольшой смазкой для локтя вы можете заставить его работать с проектами C и С++.
• Что приводит меня к следующему утверждению: не храните свои jarfiles (если вы проект Java) в своем исходном репозитории. Это удобно, но в конечном итоге вы будете ненавидеть себя за это. Двоичные файлы занимают много времени для обработки во многих системах управления версиями, и они могут занимать много места. Еще хуже то, что вы теряете информацию о них. Например, какая версия common-utils.jar проверена в Subversion, от которой зависит мой проект. Опять же, используйте Artifactory и Ant/Ivy или Maven. Если вы не Java, вы можете использовать wget или curl для извлечения зависимых библиотек из Artifactory. Опять же, не позволяйте всему делу Maven пугать вас.
• Если у вас есть проект Java, и вы не используете Maven, настаивайте на том, что код хранится в репозитории с использованием стандартного макета Maven. То есть код Java хранится в src/main/java, а файлы не Java находятся под src/main/resources. Преимущество состоит в том, что он позволяет легко перейти от проекта к проекту, а новые разработчики могут быстро найти, где что находится. Кроме того, он делает ваши файлы build.xml намного чище. Вы можете использовать любой стандартный макет репозитория, который вы хотите, но, настаивая на стандарте Maven, вы можете подавить все жалобы. "Привет, я согласен с вами, но Maven говорит, что вы поместили свой код в этот каталог. Извините, мне хотелось бы помочь, но мои руки связаны".
• Если вы используете Subversion, придерживайтесь стандартного стиля trunk, branches, tags и не слишком причудливы. Я не на 100% сумасшедший по поводу макета. (Я бы предпочел иметь main в каталоге branches и не trunk), но вы просто запутаете разработчиков и упростите поддержку, и все это будет очень мало.
• Убедитесь, что все проекты (если вы используете Ant) имеют стандартные целевые имена. Опять же, я беру на себя соглашение об именах Maven. Убедитесь, что все build.xml используют параметр description в целевых именах, и что только внутренние цели не используют description. Таким образом, ant -p работает. Также убедитесь, что все построенные артефакты находятся под каталогом target (опять же, способом Maven). Это облегчает выполнение clean, если вам нужно удалить каталог target. Идея clean заключается в восстановлении вашего макета до первоначального состояния проверки. Намного проще использовать такой инструмент, как Jenkins. Это напоминает мне...
• Используйте инструмент непрерывной сборки, например Jenkins. Это помогает вам применять свою политику и стандарты. В отличие от многих инструментов разработчики на самом деле любят Дженкинса. И вы можете добавить такие вещи, как автоматическое тестирование, checkstyle и т.д.

Ответ 4

1. Это зависит от вашего рабочего процесса. Если вы ожидаете, что все, кто когда-либо будет работать над вашим проектом, чтобы использовать eclipse, имеющую папку .classpath, хорошо, потому что он сохраняет все ваши настройки (пути к библиотеке, внешние зависимости..)

Насколько я знаю, подзаголовок не помещает папку /bin под контролем версий (это, вероятно, произошло из-за странного способа создания репозитория, как вы описали в 2.), поскольку eclipse может генерировать этот "на лету" как скоро, когда у него есть папка /src.

• обычно перемещается все под /workspace/projectName в/и удаляется/рабочее пространство.