2009-12-05 2 views
16

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

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

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

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

ответ

2

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

  • Просто разветвленный Bugs Everywhere еще раз. bzr log --limit 1 показывает последнюю фиксацию с начала октября 09. Развитие происходит медленно, но оно есть. Я еще не нырнул, чтобы посмотреть, что именно предлагает be. Документация: строго не хватает. На сайте нет даже краткого руководства по началу работы.
  • Ditz, используя клон его основной линии git Репо просто для меня не срабатывает. Google указывает, что 1,9 выпуска Ruby ломают его. Предположительно, есть git клонов, которые исправляют это, но я бы действительно не шутил с git.
  • Fossil имеет как минимум один релевантный вопрос здесь, на SO: What do people think of the fossil DVCS? (у него даже есть ответ от автора!). Большое уважение к Д. Ричарду Хиппу (автору SQLite и Fossil, а также другим безумно классным вещам, которые я могу использовать и читать только в Википедии), но я также хотел бы получить отзывы от других смертных.

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

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

+0

Некоторые могут найти мои ошибки в любом месте GUI полезным (http://www.nedprod.com/programs/Win32/BEurtle/), хотя это только Windows. Это связано с отсутствием документации по документации BE :) –

3

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

+0

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

+0

Настоящая проблема в этом случае заключается в том, что я подозреваю, что людей с значимым опытом не так много) -: – Murph

+0

Я подозреваю, что вы правы. : P Это, и инструменты еще не готовы. За исключением того, что они никогда не будут готовы, пока люди не будут их использовать. Сладкий улов-22. : P –

4

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

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

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

+0

Ошибки везде выглядят интересными Я могу поиграть с этим с моими личными вещами только потому, что могу! – Murph

+0

LOL, я бы сказал, что более чем достаточно оснований для его опроса.: D –

+0

Ну, это почти год, и я смотрю на такая же проблема ... Итак, как это сработало для вас? –

6

Fossil работает как «легко настраиваемый» Distributed Bug tracker и имеет прекрасное средство автосинхронизации, которое позволяет разработчикам делиться своими ошибками без вмешательства.

начать,

  1. Скачать ископаемое двоичного вашего выбора
  2. ископаемого нового bugs.fossil
  3. ископаемого щий bugs.fossil (работает сервер)

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

  1. Загрузить fos силь двоичного вашего выбора
  2. ископаемое клон
  3. ископаемое ще bugs.fossil
  4. создать хроны к "ископаемым синхронизации ... так что ошибки распространяются на все пользователь, как fossil self-hosting repositories demonstrate

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

Редактировать - взгляните на Customizing The Ticket System тоже.

Смежные вопросы