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

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

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

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

  1. bialix16 декабря 2009 г. в 11:20

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

    ОтветитьУдалить
  2. archimag16 декабря 2009 г. в 11:48

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

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

    ОтветитьУдалить
  3. bialix16 декабря 2009 г. в 15:37

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

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

    ОтветитьУдалить
  4. archimag16 декабря 2009 г. в 15:49

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

    ОтветитьУдалить
  5. Vladimir Sedach16 декабря 2009 г. в 19:35

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

    ОтветитьУдалить
  6. archimag17 декабря 2009 г. в 00:56

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

    ОтветитьУдалить
  7. bialix17 декабря 2009 г. в 16:58

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

    ОтветитьУдалить
  8. archimag18 декабря 2009 г. в 00:50

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

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

    ОтветитьУдалить
  9. bialix20 декабря 2009 г. в 21:06

    Я ничего не говорил о том, что лучше.

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

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

Подписаться на: Комментарии к сообщению (Atom)