Распределенный баг-трекер для работы с DVC - PullRequest
16 голосов
/ 05 декабря 2009

На данный момент мы в значительной степени подошли к распределенному компоненту для контроля версий. Я не говорю, что все идеально, но с этого момента, в основном, это просто вопрос продолжения того, что уже началось.

Распределенная ошибка отслеживания , однако, находится на начальной стадии, ИМХО. Это довольно неудобно, потому что я не могу работать с трекером проблем в дороге, тем более что у меня есть тенденция забывать, для чего были сделаны мои изменения за последние два часа. Да, я знаю, я мог бы просто вести журнал в дороге и обновлять традиционный трекер, как только я снова попаду в сеть, но все же ... Сохраняя свои опции открытыми и все такое. : P

В настоящее время я знаю только ошибок везде и Дитц - тех, которые есть с Ископаемые . Из них, я думаю, что Fossil - самый дальний, что не удивительно, учитывая, насколько тесно он интегрирован со стороной управления версиями уравнения. Мне пришлось прыгать через несколько обручей, чтобы мои соавторы даже смотрели на что-то другое, кроме SVN, но, если Fossil действительно все это, я бы не отказался сделать это снова.

Однако, прежде чем я это сделаю, я хочу спросить старших и мудрых руководителей, чем моя: у вас есть опыт работы с этими тремя? Что вы о них думаете? Вы знаете других? Пожалуйста, дайте ссылку на них, и дайте мне знать, как они поживают.

Ответы [ 4 ]

6 голосов
/ 29 марта 2010

Fossil работает как "простая в настройке" Распределенная система отслеживания ошибок и имеет удобную функцию автосинхронизации, которая позволяет разработчикам делиться своими ошибками без вмешательства.

для начала,

  1. Загрузите ископаемый бинарный файл на ваш выбор
  2. ископаемые новые ошибки.фоссил
  3. ископаемый пользовательский интерфейс bugs.fossil (запускает сервер)

ваши разработчики делают то же самое

  1. Загрузите ископаемый бинарный файл на ваш выбор
  2. ископаемый клон
  3. ископаемые ошибки Bugs.fossil
  4. настроить задание cron на 'ископаемую синхронизацию ...', чтобы ошибки распространялись на всех пользователей, как в окаменелых самозанятых репозиториях демонстрируется

Это не намного больше, чем это.

Редактировать - взгляните на Настройка системы билетов тоже.

4 голосов
/ 07 декабря 2009

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

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

В любом случае, если кто-то использует этот или подобный набор инструментов, пожалуйста, дайте мне знать, как он работает для вас, каковы ваши обстоятельства и т. Д. Сейчас у нас есть решение на три дня. старый, так что у меня пока нет большого количества данных для обмена.

3 голосов
/ 07 декабря 2009

Эрик Синк имеет несколько разумных мыслей по этому вопросу здесь - он явно обдумал это больше, чем я, но он делает один ключевой момент: у вас есть другая парадигма, когда вы имеете дело с функциями и ошибками при разработке, особенно в отношении ошибок.

2 голосов
/ 05 декабря 2009

Дополнительная информация для таких людей, как я, которые интересуются этой темой, но не могут найти достаточно релевантной информации через Google (либо их там нет, либо моего Google-фу очень не хватает):

  • Только что разветвленные Ошибки везде снова. bzr log --limit 1 показывает последний коммит с начала октября 09. Разработка идет медленно, но она есть. Я еще не погрузился, чтобы посмотреть, что именно предлагает be. Документация строго отсутствует. На сайте даже нет краткого руководства.
  • Дитц , используя клон своей основной линии git Репо просто проваливается для меня. Google указывает, что версия 1.9 Ruby ломает его. Предположительно, есть git клоны, которые это исправляют, но я бы лучше не связывался с git.
  • Ископаемое имеет здесь по крайней мере один соответствующий вопрос на SO: Что люди думают о ископаемом DVCS? (у него даже есть ответ от автора!). Я с большим уважением отношусь к Д. Ричарду Хиппу (автору SQLite и Fossil, а также к другим безумно крутым вещам, которые я могу использовать и читать только в Википедии), но я также хотел бы услышать отзывы других смертных.

Но мне все еще недостаточно. Должно быть по крайней мере пары людей, которые использовали be или ditz для нетривиального проекта - по крайней мере, достаточно, чтобы иметь возможность высказать обоснованное мнение.

Меня не волнует техническая сторона - либо проект документирует это на своем веб-сайте, либо я могу просто посмотреть на источник. Что я ищу, так это опыт реального мира: каковы были препятствия для его принятия? Чего не хватает конкретному проекту? Что бы вы добавили, что вам действительно нужно, если бы на это ушло два года оплачиваемого времени? Вещи, как это.

...