Если вы желаете присоединиться к разработке системы 2С, то вам потребуется предварительная регистрация.

Для начала определимся, что  вам потребуется для коллективной разработки:

 Во первых, вам необходимо получить доступ к Bugzilla. Если говорить кратко, Bugzilla - это Trouble Tracking System (система отслеживания проблем). Как известно, любая программа содержит ошибки. Это аксиома. И 2С - не исключение. Это одна (довольно важная) из частей этой службы поддержки. Фактически, это доступ непосредственно "на кухню" 2С, прямой контакт со службой поддержки и разработчиками.

Предположим у нас возникла проблема. Причем есть основания предполагать, что это не ваши «кривые руки», а именно проблема, ошибка. Но скорее всего, та же самая проблема возникла еще у кого-то. Давайте же посмотрим на Bugzilla Query Page. Скорее всего эта проблема уже известна и решается. И лишь в том случае, если мы нашли явную ошибку, можно открыть проблему через Enter Bug.

При запросах проблем можно делать выборку по самым разнообразным критериям. А если мы увидели интересную проблему, можно добавить комментарий, или можно добавить свой e-mail и получать регулярную рассылку по статусу ее решения.

Когда проблема устранена, она получает статус "RESOLVED", но продолжает храниться в базе. Можно сделать например, выборку по какому-нибудь пакету и посмотреть, какие проблемы в нем возникали и были решены.

Довольно частый ответ: RawHide. Это означает, что проблема решена в более свежей версии авторского софта и нет необходимости потрошить старую версию.

Регистрацию нового пользователя Багзиллы можно выполнить здесь:

http://cvs.alterplast.ru/bugs/createaccount.cgi

Ну вот, вы получили доступ к системе Bugzilla.

Во вторых, почитать статью на http://1c.alterplast.ru/gcomp/we.html и выполнить пункты 3,4,5,6 (т.к. 1 и 2 вы уже выполнили выше) и настроить софт как описано в разделе «Настройка софта» этой же статьи.

Что бы получить доступ к репозитарию необходимо связаться с администратором cvs по ICQ по номеру 115635003 с просьбой типа: «Я бы хотел участвовать в проекте 2С и мне необходимо получить доступ к cvs. Мой логин VisyaPupkin. Вот ключ, который я сгенерировал:

ssh-rsa

AAA….BBB= rsa-key- VisyaPupkin».

Админ даст вам доступ.

 Если в процессе работы у вас появилось сообщение типа «GetHostByName error», то скорее всего вы работаете через  прокси сервер. Выполните следующее в командной строке: ping cvs.alterplast.ru.

Если вы не получили положительный результат, то скорее всего ваш пинг не видит прокси, а у вашего админа «кривые руки». Но выход есть. Укажите в адресе хоста IP адрес 213.167.38.11.

Постарайтесь внимательно изучить документацию к WinCvs перед тем, как делать «коммит». Если вам непонятно это слово, значит вы еще недостаточно разобрались с программой и невнимательно читали документацию. Я не шучу.

Вот несколько советов, которые возможно тебе помогут, как когда-то помогли мне:

1)     Чекаут (Checkout) - это первое возвращение всего модуля из репозитария, т.е. получить все файлы. Чекаут делается 1 раз в самом начале. Выбери меню Remote -> Checkout module и в появившемся файловом диалоге выбери директорию, где будет храниться твоя локальная копия модуля. Директория с именем модуля будет создана в директории, которую ты укажете. Скорее всего это будет директория, где хранятся твои проекты. В появившемся диалоге установок в поле «Enter the module name» укажи имя модуля. Имя проекта в репозитарии в данном случае будет 2C (C - английская). Нажми кнопку ОК. При успешном завершении процесса, внизу программы в логе ты увидишь большое количество строк и названиями файлов проекта и в директории, которую ты указал при чекауте, появятся новые файлы;

2)     Апдейт (Update) – Позволяет получить из репозитория все изменения, сделанные другими пользователями. Обновляет только файлы вашей локальной копии. Т.е. эта команда позволяет получить новые и измененные файлы из репозитория к тебе;

3)     Коммит (Commit) – Позволяет отправить сделанные тобой изменения в репозиторий;

4)     Делай апдейт перед тем как делать коммит, чтобы убедиться что никто ничего не внес в середине между тем когда ты сделал чекаут или апдейт и завершил изменения, только смотри апдейтом не затри свои изменения;

5)     Когда апдейт будешь делать то ставь галку «криейт миссинг директориес», тогда получишь все новые папки, которые кто-то создал с содержимым. Т.е. если сделать апдейт с галкой «криейт миссинг директориес» рядом с изменениями в старых файлах ты получишь еще и новые файлы и папки (если они появились в репозитории);

6)     Когда будешь делать коммит, указывай баг, который фиксил. есть такая возможность в цвс писать в комментарии при коммите [bug 456] например и потом тело комментария. Этот комментарий автоматом добавится в багзиллу. Лучше на любой коммит делать баг. Эта история потом позволит лучше видеть ходы для новичков и самим при случае корректировать и знать что за чем. Короче правило - нет коммита без бага. Когда ты выбираешь команду коммит, там есть окошко.

Делай таким образом:

[bug N бага]

Решил проблему, которая всем мешала

тогда этот комментарий автоматом попадет в багзиллу и я по почте получу уведомление что баг пофикшен. И старайся не делать коммитов без багов. В этом и фишка "коллективной" работы;

7) Все коммиты делай отдельно. Т.е. один баг – один коммит;

8) Т.е. режим твоей работы может быть примерно следующим:

а) найти баг

б) Зайти в багзиллу

в) завести новую запись в багзилле

г) исправить баг

д) сделать апдейт

е) внести изменения

ж) сделать коммит

 з) начать работу над новым багом

9)     Ничего напортить нельзя в принципе, и если будет чего неработоспособное - откатим назад, но лучше сделать все сразу нормально, что бы не создавать проблем другим;

10) В первую очередь веди работу в направлении фикса багов. Все баги по 2С, конвертеру и всему связанному надо вносить в багзиллу;

11) Когда создаешь баг в багзилле, там есть поле аннотация,. его тоже заполнять надо. Если чего не понятно - можно потом комментариев добавить.

12) Когда баги в багзилле для себя делаешь, то указывай ответственного – себя. Когда ты берешься за решение бага сам, указывай «ассигнед». Это просто для того, чтобы четко видеть кто чем  уже занимается. Ассигнед - это когда у бага появился кто-то ответственный, кто над ним работает. А если в баг добавлен комментарий система оповестит тебя по почте. Я лично к почте еще привесил смс посылку на мобильник, так что получаю все мгновенно;

13) New баг - это когда его просто нашли, но еще никто его не делает;

14) Фиксед – это когда сделан баг, и ждет подтверждения (верификации). А подтверждается по идее тем, кто баг создал, но не обязательно. То есть, если баг сам для себя делаешь, то и закрываешь его сам, но можно потом баг передать кому то еще, или себе, если ты вдруг видишь что он не за тобой, но реально твой. На практике баг подтверждается ответственным за компоненту;

15) В общем случае важно, чтобы баг был не только твоим собственным а его кто-то разделял. Тогда вы сможете быстрее решить проблему и выбрать более лучший способ;

16) Разбирать/собирать файлы нужно или утилитой сборки/разборки. Дело в том, что когда будешь работать над 1 уровнем, тогда раром нельзя работать будет (посмотри 515 баг)

Итак, допустим, доступ есть, софт настроен, CheckOut сделан. Можно начинать работу. Если у вас все получилось, то поздравляем вас, вы присоединились к коллективной разработке проекта 2С. Если вы не знаете, в каком направлении двигаться, то можете поискать новые баги в Багзилле.

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

Ну вот и все! Удачи!

Автор файла: reminder, gre

Версия 0.3b от 18.10.2004 16:59