Каков предпочтительный рабочий процесс с SVN (Subversion) с использованием XCode (Objective-C)?

Question

Мы использовали svn с xcode в течение 2 недель и столкнулись с множеством неловких проблем, которые, вероятно, вызваны неправильным использованием и неопытностью.Наша команда ios состоит из младших членов команды, так как все старшие программисты не могут писать target-c.

1. Файлы ресурсов не включаются в SVN, каждый раз, когда дизайнеры обновляют ресурс (изображения,sqlite), разработчики должны вручную импортировать файлы в проект.Программисты объясняют, что это унаследованная проблема с xcode, которая в деталях заключается в том, что ресурсы разархивируются при первом запуске программы, а для обновления ресурсов им необходимо напрямую скопировать ресурсы в проект и симулятор.
2. Разработчики всегда проводят рефакторинг при слиянии.Они объясняют, что каждый раз, когда они объединяются, проект неожиданно прерывается, и им приходится перезапускать с нуля, что, предположительно, быстрее.
3. Корневой каталог изобилует каталогами версий, что совсем не правильно.Я знаю, что вместо этого следует использовать теги, но не знаю точно, когда и как.
4. Я возился с КИ, в частности с Хадсоном, но столкнулся с ошибками с помощью ведомого компоновщика (отсутствует xcodeproject).Стоит ли использовать вместо этого скрипты bash?

Итак, каков предпочтительный рабочий процесс для управления версиями под Mac?

Answer 1

Вы упомянули ряд проблем, некоторые из которых IMO имеют мало общего с Xcode или Subversion.Давайте возьмем ваши пронумерованные элементы:

1. Subversion может абсолютно обрабатывать файлы ресурсов, и вы должны использовать их для управления этими файлами.Разработчиков можно и нужно научить использовать svn для проверки и ввода файлов в командной строке или дать (и обучить) одному из клиентов svn с графическим интерфейсом, таким как Версии .

2. Похоже, что ваши младшие разработчики также должны быть обучены Subversion.Это правда, что слияние может вызвать проблемы, но ничто из того, что могло бы заставить вас начать все с нуля.У многих магазинов есть ряд простых правил, таких как: а) основная ветка разработки всегда должна создаваться без ошибок или предупреждений;б) Если вы нарушаете основную ветку разработчика во время слияния (или делаете что-то еще), вы можете исправить это как можно скорее.Разработчики могут объединять свои изменения и исправлять любые возникающие проблемы до того, как они перейдут в основную ветку, поэтому у основной ветки мало поводов для когда-либо нарушения.

3. Обычная установка Subversion имеет каталоги транк , ветки и теги .Вы не должны делать это таким образом, но люди делают это, потому что это работает хорошо.Пожалуйста, прочитайте (и попросите вашу команду прочитать) Контроль версий с Subversion для тщательного рассмотрения всех этих проблем.Печатные копии доступны от O'Reilly - купите несколько, по крайней мере.Точно, как вы организуете свой репозиторий, не так важно, как заставить команду согласиться (и придерживаться) какой-то организационной схемы.

4. У меня нет мнения по поводу Хадсона или непрерывногоинтеграция вообще.Тем не менее, я сомневаюсь, что внедрение CI очень поможет, пока вы не разберетесь с другими проблемами.

Другие мысли:

• Пришло время вашим старшим разработчикам изучить Objective-C.Попросите младших разработчиков научить их - обе группы многому научатся.
• Xcode действительно не должен быть здесь важным фактором.Конечно, он имеет встроенную поддержку Subversion, но это все еще просто клиент SVN, и пользователю все еще нужно знать, как выполнять ветвления, как объединять, как разрешать конфликты, каковы соглашения для создания веток и тегов именования и тому подобное.ваша организация и т. д.

Чтобы ответить на ваш фактический вопрос, типичный рабочий процесс выглядит примерно так, в зависимости от местного соглашения:

• Разработчик начинает работать над задачей.Открывает задачу в системе отслеживания дефектов, вводит анализ исправляемой ошибки или подлежащей реализации функции, вводит план или схему для кода, подлежащего изменению или добавлению, вводит оценку времени или уровень сложности или подобное, возможно вводитплан тестирования для изменения.
• Разработчик создает новую ветку для изменения или обновляет свою собственную ветку с основной веткой.
• Разработчик внедряет изменения, фиксируя свою ветку разработкичасто, чтобы избежать потери работы и чтобы они могли легко вернуться к ранее зафиксированным версиям.
• Когда все будет готово, разработчик проверяет основную ветку разработки в другом каталоге на своей машине.Затем они могут объединить изменения в этот каталог, чтобы гарантировать, что проект будет собран и ничто не нарушит их изменение.
• Разработчик фиксирует измененную основную ветку dev.
• Задача обновлений разработчика в системе отслеживания дефектов.

Обычно между разработчиками существует неформальное общение, так что два человека не заканчивают вносить серьезные противоречивые изменения в одну и ту же часть кода одновременно.Некоторым из этого может заниматься человек, назначающий задачи, но разработчики, которые работают хорошо как команда, обычно имеют некоторое представление о том, кто над чем работает.Если это не так, или даже если это так, вам, возможно, придется применить некоторые методы для улучшения коммуникации, такие как периодические проверки кода, совместные обеды и т. Д.

Answer 2

В целом, я бы сказал, что первый шаг - хорошее понимание того, как использовать svn в среде командной строки.Существуют некоторые основные операции (тегирование, установка свойства ignore), которые трудно (невозможно?) Выполнить в XCode (по крайней мере, в XCode 3).Для разработчика, который знаком с тем, как использовать svn в универсальной среде Unix / Linux, им не так много нужно изучать, что специфично для XCode - просто исключите каталог build и файлы настроек XCode для каждого пользователя (см. Ниже).

(1.) Неверно.Там нет причин, ваши изображения и т. Д. Не могут быть включены в SVN.Обычная настройка XCode будет состоять в том, что ваши изображения (и т. Д.) Будут находиться в папке «Ресурсы» в источнике и будут скопированы в образ приложения как часть фазы «Копирование ресурсов комплекта» сборки XCode.

Вся папка проекта XCode должна быть включена в svn, со следующими исключениями:

• каталог 'build'
• настройки / история XCode для каждого пользователя в AppName.xcodeproj/*.pbxuser и AppName.xcodeproj / *. mode1v3

Скорее всего, вы захотите сказать svn игнорировать эти каталоги, выполнив что-то вроде:

 svn propedit svn:ignore .

(2.)без причины вещи должны происходить "необъяснимо".Если ничего другого, запустите руководство svn update в окне терминала, и оно точно скажет вам, какие файлы оно обновило.

(3.) Стандартная практика - иметь "trunk", "tags" и"ветки" каталогов в корне.Магистраль - это то, с чем вы обычно работаете, поэтому первый шаг, который должен сделать новый разработчик, - проверить последнюю версию «магистрали»

svn co svn+ssh://host.com/repository/AppName/trunk AppName

. После внесения некоторых изменений сохраните их в репозиторий с помощьюsvn commit (или «Подтвердить изменения ...» в меню «SCM» XCode).Получить изменения, сделанные другими разработчиками с помощью svn update (или «Обновить до» в XCode).

Чтобы отметить выпуск, скопируйте trunk в tagname:

svn cp svn+ssh://host.com/repository/AppName/trunk svn+ssh://host.com/repository/AppName/tags/version1

(4.) У меня нет опыта работы с Hudson, поэтому я не могу это прокомментировать, хотя «отсутствующий xcodeproject» звучит так, как будто каталог svn может отсутствовать в каталоге AppName.xcodeproj.

Answer 3

Я в целом согласен с ответом Дэвида Гелхара.

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