Что входит в систему контроля версий?

Question

Дано: http://developer.android.com/resources/faq/commontasks.html#filelist

1. Каковы наилучшие практики для перевода ваших проектов в систему контроля версий?Я спрашиваю, потому что если вы просто щелкнете правой кнопкой мыши по своему проекту, выберете команду и т. Д., Вы получите папки / bin & / gen, .classpath, а также все элементы, связанные с Eclipse.наследование проекта с помощью ... / workspace / projectName et al.Включено, как я могу очистить это, чтобы включить только элементы, относящиеся к вышеупомянутому URL?

Answer 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 в соответствии с предпочтениями Eclipse Team.

Answer 2

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

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

res/
src/
build/
.idea/

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

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

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

Answer 3

Вот несколько основных моментов:

• Не храните в контроле версий то, что создает ваш исходный код.Например, если вы создаете jarfile, не храните этот jarfile под контролем исходного кода.
• Source control for source.Если у вас есть релизы, используйте репозиторий релизов, например Artifactory .Не позволяйте вещам Maven отпугивать вас.Возможно, вы не используете Maven (сейчас), но инструмент репозитория Maven имеет стандартный формат и позволяет легко находить ваши выпуски.Artifactory может работать с Ant / Ivy, и, немного смазав локоть, вы можете заставить его работать и с проектами C и 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, вы можете подавить все жалобы. «Эй, я согласен с вами, но Мейвен говорит, что вы поместили свой код в этот каталог. Извините, я бы хотел помочь, но мои руки связаны»
• Если вы используетеSubversion, придерживайтесь стандартного стиля trunk, branches, tags и не будьте слишком изощренными.Я не на 100% без ума от макета.(Я предпочел бы иметь main в каталоге branches, а не trunk), но вы просто запутаете разработчиков и усложните поддержку, и все это за очень небольшой выигрыш.
• MakeУбедитесь, что все проекты (если вы используете Ant) имеют стандартные целевые имена.Опять же, я позаимствовал соглашение об именах Maven.Убедитесь, что все build.xml используют параметр description в именах целей, и что только внутренние цели не используют description.Таким образом, ant -p работает.Также убедитесь, что все встроенные артефакты находятся в каталоге target (опять же, в стиле Maven).Это просто сделать clean, если вам нужно только удалить каталог target.Идея clean состоит в том, чтобы восстановить ваш макет до первоначального состояния оформления заказа.Упрощает использование такого инструмента, как Jenkins .Что напоминает мне ...
• Используйте инструмент непрерывной сборки, например Jenkins .Это поможет вам обеспечить соблюдение вашей политики и стандартов.В отличие от многих инструментов, разработчикам действительно нравится Jenkins.И вы можете добавить такие вещи, как автоматическое тестирование, стиль проверки и т. Д.

Answer 4

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

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

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