Перейти к содержанию
    

bialix

Свой
  • Постов

    162
  • Зарегистрирован

  • Посещение

Репутация

0 Обычный

Информация о bialix

  • Звание
    Частый гость
    Частый гость

Контакты

  • Сайт
    Array
  • ICQ
    Array

Информация

  • Город
    Array

Посетители профиля

1 151 просмотр профиля
  1. Молодцы, оперативно развернули сайт и форум. Через форум сразу и баги можно описывать и вопросы создавать. Для тех, кто хочет участвовать в разработке -- тем можно будет публиковать свои ветки на github или gitorious (бесплатные открытые хостинги для кода). Я бы только посоветовал добавить скриншоты на вашем сайте.
  2. ОК, это уже хорошо. Ммм. В таком случае бурного развития ждать не стоит. По моему опыту новые программисты будут подключаться лишь в том случае если у них будет интерес что-то доделать под себя либо пофиксить баг, который касается их лично. В остальном проект должен двигать либо изначальный автор либо текущий maintainer. Только консультации... это не выход. Например, кто-то найдет какую-то неприятную ошибку в вашей программе (не потому что она плохо написано, такое случается даже с очень хорошо написанными программами). Кто будет чинить ошибку? Совершенно верно. GPL v2 будет оптимальным выбором. Это не нужно. Обычно достаточно указать в доп. документации. Первоначальные права под Copyright будут все-таки записаны под именем твоего программиста и тебя. Я попытаюсь еще раз донести мысль: сделать проект открытым -- это не значит. что вы при этом автоматически самоустранитесь от него, а кто-то другой по доброте душевной будет все делать за вас. Такой фокус практически никогда не срабатывает. Вам нужно будет продолжать ему уделять время, хоть немного. OK. Дальше надо определиться где хостить проект (на бесплатном Open-Source хостинге или на своем сайте). Использовали ли твой программист систему контроля версий при работе над проектом и какую? Собираетесь ли вы публиковать свой репозиторий или предпочтете завести совершенно новый с нуля (первый вариант более предпочтителен, но может быть у вас там есть приватная информация, которую вы предпочли бы скрыть)? Чтобы привести код к состоянию, готовому к использованию другими программистами, надо по крайней мере: 1) Привести все исходники к единому стилю (любому), добавить в шапку исходника комментарии про авторские права и указание лицензии кода. Очень неплохо бы использовать doxygen-форматирование, но не обязательно 2) Если в исходниках использовались комментарии на русском языке -- их желательно перевести на английский либо убедиться, что они в кодировке UTF-8. Поскольку ваш проект кросс-платформенный, то кодировки типа cp1251 вызовут неудовольствие у линуксоидов. 3) Желательно иметь написанный Makefile либо хотя бы batch-файл для сборки клиента из исходников. Как я помню Qt использует свою систему сборки, в любом случае нужна инструкция по сборке, которая бы позволяла собирать без запуска IDE. 4) Нужны хотя бы краткие описания и инструкции: как собрать бинарник, как настроить базу, как пользоваться программой (хотя бы в общих чертах). Список можно продолжать. Вышесказанное -- это минимум миниморум на мой взгляд, если хотите чтобы ваш проект не зачах а имел будущее. Когда вы закончите с описанными приготовлениями надо будет озаботиться минимальным сайтом и регистрировать проект на хостинге. Это может получиться не очень быстро, так что придется упорно потрудиться. Более конкретные вопросы наверное лучше будет обсуждать по мылу. :-) Я говорил о лицензионной чистоте. Ты уже ответил на этот вопрос. На текущем этапе было бы неплохо, если бы вы хотя бы подготовили к публикации имеющийся инсталлятор клиента и инструкцию по установке/настройке базы. Уверен, не только я хотел бы пощупать вашу программу.
  3. Стоп! А кто тогда ты? Какое отношение к коду имеешь? Кому принадлежат авторские права? Попробовать можно. Я могу помочь организационно, помочь с инсталляторами, организацией проекта и сайтом. Однако писать на плюсах для Qt я не буду. Если моя помощь интересна, я хотел бы узнать насчет чистоты кода, который предполагается сделать открытым. Не понял про аватар. Мой аватар -- это буква мю. На лончпаде -- это стандартное оформление. Лончпад -- не мой сайт. Мой bialix.com.
  4. Очень похоже на попытку слива. Если будет инструкция по ручной установке, то можно попробвать сотворить автоматический инсталятор. Это не сложно. А я до сих пор плюшками балуюсь. В основном имею отношение к bzr. https://launchpad.net/~bialix Если есть уже готовый толстый клиент. то переписывать все с нуля под Php/Python на сервере и HTML+AJAX на клиенте -- это фактически все писать заново. Советовать все горазды. Кто готов своими руками это сделать? Человек предлагает готовый проект задаром. Это вам не плюшками баловаться, это реальная работа. Конкретные вопросы: 1) нафига нужен сервер? И так ли он обязательно нужен? Скажем на моей маленькой фирме комплектухой занимается один человек. Нафига ему мучаться с сервером? Может стоило посмотреть в сторону sqlite? Уверен, что в Qt есть поддержка разных баз данных. И одновременная поддержка MySql и sqlite не будет чем-то героическим. 2) Как вы себе понимаете "сделать проект опен-сорсным"? Просто выложить его на Google Code или sf.net -- этого далеко не достаточно. Вы должны продолжать уделять ему время. Надеяться на то, что народ побежит толпами вам помогать на первых порах даже не стоит. Я вам серьезно говорю, я уже наелся опен-сорса половниками. Там есть свои законы, как проект будет жить и развиваться. Сам по себе он развиваться не будет. Сам по себе он загниет и зачахнет.
  5. Периодически такую программу народ спрашивает. Потребность в ней есть. Однако, я бы посоветовал сделать какую-то простую демку, работающую без сервера. И еще: я конечно понимаю, что Windows в последние годы стала ОСью, о которой в приличном обществе не найдется добрых слов, но я вас уверяю у вас будет масса благодарных виндовс-пользователей если вы не будете их игнорировать и сделаете человеческий инсталлятор для клиента и сервера для винды. Я имею некоторый опыт участия в опен-сорс проекте как разработчик и maintainer (windows-версии). Могу подсказать и предостеречь от очевидных ошибок.
  6. Готовы аргументировано за базар ответить? Т.е. в svn всё, ну просто всё уже не сырое? и даже этот любимый всеми merge? commit и diff не покажут разницу конечно. merge -- покажет. Это твое личное мнение. Я имею представление, поэтому и советую. Для полного новичка изучать и использовать, что централизованную, что распределенную систему -- абсолютно фиолетово, у него просто нет еще стереотипов в мозгу. Это ваш выбор, который я не смею оспаривать. Посему -- умолкаю.
  7. под виндой начните с bzr или hg. пользовать централизованную систему а-ля svn на одном компе -- нецелесообразно.
  8. http://gnuwin32.sf.net рулит если често без всякого msys тем что merge tracking так в svn до ума и не довели. по крайней мере то, что я прочитал о поддержке в версии свн 1.5 вызвало только грустную ухмылку. Те кто плотно работал с ветками и их объединением в распределенных системах, те поймут -- свн предлагает полумеры. Но это ее личное дело. Гм. как говорится -- без комментариев. Если плюсик в центре никакие аналогии не вызывает, то да. Насколько я могу судить плюсик в квадратике или кружочке используется во многих графических пакетах для работы с разворачиванием веток в TreeView виджетах. Вы похоже плотно сидите в командной строке, только так я могу для себя объяснить вашу реакцию. Сейчас один из разработчиков Базара снова вернулся к реализации нативной поддержки CR-LF. Так что надежда только укрепилась. Любые внешние скрипты -- это подпорки. В марте-апреле этого года я пытался написать патч для Базара для поддержки концовок строк. Поверьте мне просто на слово -- это только кажется, что там все легко. Есть много нюансов, которые нужно учитывать, чтобы вся система в целом работала корректно.
  9. Не надо писать GIT MERCURIAL BAZAAR все в верхнем регистре. Это не аббревиатуры. Это имена собственные. Должно быть Git, Mercurial, Bazaar. Окей? Долой безграмотность. Имеет, если охота использовать коротко живущие ветки для реализации каждой отдельной фичи. Почитайте UQDS: divmod.org/trac/wiki/UltimateQualityDevelopmentSystem Обратите внимание на то, что добрая половина документа -- это объяснение почему ветки это хорошо. Плюс гит имеет хорошую двухсторонюю работу с нативными свн-ветками, т.е. можно взять свн код, затащить его в гит, там поработать, объединить с транком, а в конце просто сделать push из гита назад в свн. Базар это тоже умеет, но гит вам понравился больше. Извините? Это вы о чем? Обратите внимание на этот скриншот: http://qbzr.googlegroups.com/web/qlog.png Это вам что -- не граф ревизий? Вы че, серьезно? Я уже слышал этот аргумент, что в Базаре чересчур много понятий. Спорить с ним не буду, я скорее согласен с ним, чем наоборот. НО! Я готов терпеливо объяснять, как можно прожить не вникая в эти тонкости и не заморачиваться. Мой подчиненный на работе так и живет: освоил базовый набор команд и ему хватает для эффективной работы. Так что если не пугаться и отвлечься от туториалов, то освоиться будет так же легко, как и в hg. --- Ребята, вот что я скажу. У каждой из 3х систем есть свои достоинства и недостатки. На первый взгляд все достоинства и недостатки не видно. Иногда даже через пару месяцев на все грабли можно не наступить. Сегодня Базар -- это достаточно хорошая система. В чем-то лучше, но в чем-то и хуже других 2х. Весь вопрос в том, какие достоинства вам важны в первую очередь и с какими недостатками вы согласны мириться. Делать выбор системы на основе эмоций -- гиблое дело. Делать выбор системы только потому что в форуме вам отвечает кто-то толковый -- тоже не самый оптимальный вариант. Однако, как ни странно, если взвесить за и против всех 3 систем с холодным сердцем и ясным рассудком, то для среднестатистического (3 руки, 3 ноги, 1,5 глаза) пользователя я бы порекомендовал начинать с Меркуриала. Но лично я с Базара на Меркуриал переходить не буду ни при каких обстоятельствах. Может быть на Гит когда-нибудь, но я не уверен. Остается еще слабая надежда, что главразрабы Базара таки доделают его до ума (в плане скорости и поддержки концовок строк).
  10. Создатель Cogito сегодня является официальным maintainer git. Если уж искать чего-то, то имеет смысл смотреть в сторону GUI, типа QtGit и проч.
  11. Проект на 73 метра??? И это все текстовые файлы или там есть и бинарные? Сравнение git commit нечестное, потому что надо учесть, что git add делает "предкоммит". В остальном -- я скорее согласен с этими цифрами, чем нет. 73 метра -- это 73 метра. bzr сосет на проектах больше 20 метров. Ну и до кучи: что за система у вас (версия Линукса, размер оперативной памяти, частота проца, файловая система?). bzr ставили из пакетов или руками? Нет, использовать bind+update в такой схеме не правильно. Вместо bind+update вы должны запускать команду pull. Если ветки разошлись (branches are diverged) нужно делать merge.
  12. Да, правильный вывод. Hg делает переименование как две операции: copy+delete, поэтому после переименования история дублируется (как результат операции copy). Хотя это обещают исправить, так что может быть в ближайшие 6-12 месяцев этьот недостаток действительно устранят. Базар отслеживает файлы по уникальным идентификаторам (грубо: аналог inode в линуксовой файловой системе). Поэтому при переименовании файла идентификатор и его история не меняется, меняется только текущее имя файла. Всё. К сожалению, просто переносить свой опыт из CVS/SVN напрямую в Базар нельзя. Потому что у них разная внутренняя модель, тот базовый стержень вокруг которого все крутится. Я говорю не о технической реализации репозитория, а именно о наборе базовых идей, на основе которых построена вся реализация Базара. У Гита своя модель, у Меркуриала своя. Где-то они имеют общие точки соприкосновения, где-то нет. Вот например команда pull. В SVN такой команды нет, ближайший аналог svn update, в результате рабочая копия будет обновлена. В Hg эта команда просто копирует ревизии из одного репозитория в другой и не обновляет рабочую копию. После pull обычно надо сделать или update или merge. В Git команда pull -- это на самом деле 2 разные команды, выполняемые паравозиком: fetch (копирует ревизии из одного репозитория в другой) и затем merge или rebase в зависимости от ключика командной строки. Если две ветки разошлись, то они будут объединены. В Bzr pull копирует новые ревизии, но только в том случае если ветки не разошлись, т.е. локальная ветка является родителем для другой ветки, и все новые ревизии спокойно ложатся как продолжение истории (без merge). Это соответствует fast-forward merge в терминах Git. Видите? Простой термин, pull в переводе на русский -- это "вытянуть", "вытащить", "высосать" -- а во всех 3 системах она работает чуточку по разному. Да? Плюс еще путаница в терминологии. В hg и git репозиторий -- это главное понятие, а ветка она как бы виртуальная внутри репозитория. В bzr существуют 3 отдельных понятия: репозиторий как хранилище ревизий; ветка, как конкретная история проекта; рабочая копия, как собственно файлы, с которыми вы работаете. Причем они могут присутствовать все одновременно, или некоторые части могут отсутствовать. Это зависит от желаемого сценария работы. Вы хотите svn-like с checkout? А зачем diff+patch? Для этого есть merge. Я не понимаю этой фразы. Минимальный геморрой при объединении как бы гарантирует любая распределенная система, потому что merge -- это одна из базовых команд. Проблемы с русскими буквами в комментариям к фиксациям + проблемы с русскими именами файлов. Совсем недавно ставил msysgit и в очередной раз понял, что моим требованиям он не удовлетворяет. Вы ставили bzr из готового пакета? У bzr объективно время старта долгое 100-200 мс, частично из-за того, что система на питоне писана. Так что объективные цифры (time) был бы интересен. Хотя объективно и субъективно все равно он будет чуток медленнее git и hg. Под Линукс с Gnome возможно будет интереснее использовать плагин bzr-gtk. Пока только как команды: qbrowse, qlog, qcommit, qdiff и проч. Еще раз повторюсь. Переносить напрямую свой опыт из CVS/SVN в распределенные системы (любые!) -- будет огромной ошибкой. Не считайте себя супер спецом только потому что вы уже 10 лет работали с CVS. Некоторые вещи придется переучивать и ломать стереотипы. Идеей фикс разрабов bzr была мысль, что для понимания принципов работы с bzr не нужно знать как система устроена внутри. Но я могу и рассказать. Для того, чтобы обмениваться историей между двумя ветками, которые имеют общую историю. Для централизованного стиля работы: есть "главная" ветка на условном сервере. по терминологии она зовется master branch Чтобы начать работу локально: bzr checkout URL Будет создана локальная рабочая копия с историей, "привязанная" к серверу (bound branch) Поработали. status, diff, commit При commit новая ревизия автоматом уходит в главную ветку и в локальную ветку, обе ветки таким образом засинхронизированы. Если кто-то другой (ваш коллега по работе) уже успел сделать commit в главную ветку до вас, то вам нужно синхронизировать локальную ветку с главной. Для этого используется команда update. После update вы можете делать commit. Собственно базовый набор команд. Радикально не отличается от svn, и даже push/pull в таком сценарии обычно не используется. Push/pull -- это прежде всего для синхронизации двух независимых веток. Разница небольшая, но она есть. Но в принципе копирование средствами ОС -- это вполне легальная операция. Приблизительно, да. Нет, нет и нет. Если у вас централизованная схема работы -- все так, смотри выше.
  13. Вы полезли в глубокие дебри bzr не разобравшись в основах. Вот совсем свежая статья, которая рассматривает основы: http://hlabs.spb.ru/development/versions/bazaar.html Или... А может ну его этот дурацкий базар, если гит вам кажется более проработанным? Под виндой тока гит не запускайте, и будет вам щастье. Если вам не тяжело, то озвучьте размер своих проектов где тормозит: количество файлов/каталогов, и глубину истории? Не поленился посмотреть в ман на гит. Команда pull внутри вызывает команду fetch, которая подтягивает ревизии, а затем делает merge с локальной рабочей копией. Либо может сделать rebase при использовании соответствующего ключика. Может вам будет интересно, что в hg команда pull делает только fetch, а затем нужно принудительно обновлять рабочую копию командой update (О ужас! опять эта дурацкая команда!) В bzr команда pull работает также как в гите. Боюсь, что знаток я здесь один в единственном числе. Та статья написано достаточно давно, меркуриал за прошедшее время улучшил свою поддержку переименований, однако все еще остаются тонкие нюансы. Так что просто делать свой выбор на основе той статьи я бы не советовал. О каком непостоянстве речь? У базара имеется полная обратная совместимость со всеми прошлыми форматами репозитория вплоть до 2006 года. Хоть эти смены форматов и выглядят как хаос, но если пользоваться только форматом по умолчанию, который уже не менялся 1 год, то вас как пользователя эти вопросы не должны мучать в принципе. Все, повторяю еще раз ВСЕ форматы постоянно тестируются автоматической системой тестов, количество тестов на сегодняшний день превышает 15000, еще раз буквами: пятнадцать тысяч. Данные в репозитории не портятся, этому можно доверять. Однако это не отменяет необходимость делать периодические бэкапы. При использовании любой системы контроля версий. Командная строка ЕСТЕСТВЕННО работает надежнее, потому что она была и есть с самого начала проекта. Я пользуюсь базаром в командной строке с 2005 года. На винде. FAR рулит. Для винды рекомендую использовать плагин QBzr в качестве комбинированного подхода: команды все равно запускаются из командной строки, но весь интерфейс графический. Кстати этот же самый интерфейс использует и TortoiseBzr :-) Плагин QBzr включается в стандартную поставку для винды (если вы используете standalone installer). -------------------------------- Попробую все-таки ответить на вопросы yes. Да. Можете. Не нужна. Рабочая копия -- это для работы, вся история самодостаточна. Нет. commit == создание новой ревизии в локальном репозитории, push == пересылание имеющихся ревизий между двумя репозиториями. Нет, merge не делает commit. Фиксацию после merge нужно делать самому. Я не понимаю, что именно вам объяснять. Может начать с азов? Создать новую ветку локально: bzr init В текущем каталоге будет инициализировано новое рабочее пространство и появится каталог .bzr для хранения внутренней информации. Создаете/копируете файлы в рабочий каталог. Их нужно добавить, что bzr знал о их существовании и отслеживал изменения в файлах: bzr add Затем вы наверное захотите сохранить текущее состояние файлов в виде новой ревизии: bzr commit Потом вы еще их будете менять, дописывать-переписывать. Чтобы увидеть, что изменилось после последней фиксации: bzr status bzr diff Как только будете готовы, снова фиксируете: bzr commit Чтобы просмотреть историю фиксаций: bzr log В какой-то момент вы захотите опубликовать свою ветку или просто скопировать ее на сервер/ USB-флеш/ на соседнюю машинку по сетке. Вот тут вам и пригодится команда bzr push, она создат (если надо) новую ветку в месте назначения и скопирует туда всю историю вашей ветки, т.е. все ревизии. После push вы получаете фактически копию своей ветки, но чаще всего без рабочей копии. В случае локального push -- т.е. на другой диск на той же машинке -- рабочая копия будет восстановлена автоматически. Иначе чтобы воссоздать рабочую копию делаете: bzr checkout Чтобы сделать копию ветки локально (например, чтобы попробовать написать какой-то новый код, октором вы не уверены, что сразу получится) делаете bzr branch Опять же будет создана копия вашей ветки, чаще всего уже с рабочими файлами. Эти две ветки связане некоторым родством (потому что имеют общую историю). Далее, чтобы между ними обмениваться ревизиями, можно использовать pull/push/merge pull = вытягивает историю из другой ветки и копирует ее в текущую рабочую ветку push = наоборот: передает ревизии из текущей рабочей ветки в другую ветку merge = объединяет ревизии из другой ветки в вашу текущую рабочую ветку и пытается объединить изменения в файлах. Если возникают конфликты, то создаются специальные файлы THIS/BASE/OTHER. Конфликты нужно порешать (отредактировать файлы), затем сделать bzr resolve Когда вы будете удовлетворены состоянием ветки после merge нужно зафикисировать опять же командой bzr commit.
  14. В чем-то похоже, в чем-то отличается. Так что думаете вы не совсем правильно. Полегче на поворотах, уважаемый. Вы cvs/svn никогда не пользовались? А какой командой в гите вы обновляете рабочую копию после pull? Печальное зрелище. А вы и не заморачивайтесь поначалу. Работайте по самому простому сценарию. Я не знаю, что вы конкретно пробовали и что хотели достичь. Попробуйте поточнее сформулировать вопрос. 1) Не "переименовать". 2) Да, любой репозиторий может быть как центральным (мастером), так и подчиненным. commit = фиксация локальных изменений в ветке в виде новой ревизии. Фактически запись истории. Полный аналог svn commit. push = отправка новых ревизий из своей рабочей локальной ветки в любую другую. Предлагаю ознакомиться с глоссарием: http://groups.google.com/group/ru_bzr/web/...%80%D0%B8%D0%B9 pull делается когда у вас две ветки не связаны по принципу master-checkout; update как раз наоборот для связанных веток; merge для объединения истории двух веток.
  15. Извините, что встреваю, но закрытый (приватный) ключ остается на локальной машине, а открытый ключ в формате openssh -- на серваке. Приватный ключ потом загружается в pageant и красота (до следующей перезагрузки).
×
×
  • Создать...