среда, 16 декабря 2009 г.

git-репозиторий с hunchentoot

С исходным кодом Hunchentoot невозможно работать, ибо он лежит под Subversion. Это просто ненормально, 2010-й год на носу. Ладно, теперь есть и под git: http://github.com/archimag/hunchentoot. Обязуюсь регулярно синхронизировать с основным репозиторием и не вносить каких-либо своих изменений. Т.е. это будет чистая копия. Может кто-нибудь форкнет, в конце-то концов...

9 комментариев:

  1. Какая проблема просто использовать git-svn? Прямо уж "невозможно". Дожились...

    ОтветитьУдалить
  2. @bialix
    Дожились до чего? И как, по Вашему, я собственно сделал это репозиторий?

    Проблема в том, что реально нельзя эффективно работать над форком и при этом регулярно вызывать git-svn rebase - больно напряжно. А вот "чистый" git репозиторий, я надеюсь, повышает вероятность форка.

    ОтветитьУдалить
  3. нужно иметь 2 ветки: чистый mirror svn repo -- это upstream + ваши доработки в отдельной ветке. Из upstream в свою ветку делать merge новых ревизий.

    Примерно так мы работаем в bzr (у нас тоже есть bzr-svn). Я наверное чего-то фундаментального не понимаю в git, раз описанный мною сценарий почему-то вами не применим.

    ОтветитьУдалить
  4. @bialix
    Кто сказал, что не применим? Но, вы заметили, что я пообещал не вносить в этот репозиторий никаких своих изменений и регулярно сихронизироваться с svn-репозиторием? Интересно, зачем я это делаю?

    ОтветитьУдалить
  5. Форкать надо было до 1.0. Сейчас все кого это волнует уже переделали свой код под новый интерфейс, обратного пути нет. А новые выделки Ганса и ко меня совсем не радуют. Блин надо свой сервер доводить.

    ОтветитьУдалить
  6. @Vladimir Sedach
    Мне версия 1.0 понравилось, если бы не эта история с отладкой, то вообще было бы хорошо. Меня больше беспокоит ограниченность модели "поток на соединение", необходимо, что бы сервер предоставлял возможность обработки на основе epoll и фиксированного набора потоков. В общем, как раз версия 1.0 открывает перспективы для реализации такого поведения (необходимо написать соответствующий taskmaster), но остаётся препятствие в виде usocket - на мой взгляд необходимо переделать кода на базе iolib.

    ОтветитьУдалить
  7. Понял.
    Фундаментальная разница между git и bzr в том, что пользователи bzr мыслят в терминах веток, а пользователи git в терминах репозиториев.
    В таких ситуациях ветки удобней. Боюсь, вы меня не поймете.

    ОтветитьУдалить
  8. > В таких ситуациях ветки удобней.
    > Боюсь, вы меня не поймете.

    А на самом деле мне всё равно :) Меня мало беспокоит вопрос, как из система контроля версий объективно лучше (подозреваю, правда, что на него нет ответа). Среди пользователей Common Lisp из вменяемых систем доминирует git.

    ОтветитьУдалить
  9. Я ничего не говорил о том, что лучше.

    git -- объективно самый популярный сегодня и не только среди пользователей Common Lisp.

    ОтветитьУдалить