Здравствуйте, Ziaw, Вы писали:
Z>Драсьте. Ты тут опенсорсному проекту даешь советы по модели совместной разработки, а потом спрашиваешь, причем тут opensource? Z>Практически все системы контроля версий умеют обмениваться патчами по почте. Это не значит, что твой процесс подходит всем.
Прости, но описанный тобой процесс "всё через веб" не позволяет как-либо контроллировать качество предлагаемых патчей.
Здравствуйте, adontz, Вы писали:
A>Компилировать, запускать, тестировать (unit, performance), анализировать возможные последствия. Performance тоже важен. Если с вижу хорошая фича затормозит PEG парсер в 20 раз, совершенно неочевидным способом, то что делать? Ой, revert, ой, извините?
Если на что-то не сделан автотест рано или поздно ручное тестирование слажает. Ой, revert, ой, извините тоже вполне нормальный сценарий в транке.
Z>>Не понимаю, откуда у мейнтейнера версия отличная от версии на сервере, у него какой-то приватный форк? A>Потому что мейнтейнер имеет доступ до других патчей, да и, сюрприз-сюрприз, сам что-то делает. А на сервер не выкладывает промежуточные, не рабочие версии. У тебя не бывало, чтобы ты делал локальный коммит для фиксации этапа задачи? Этап пушить нельзя, только всю задачу, иначе на сервере будут неработающие исходники.
И зачем применять патчи в неработающие исходники? Мухи отдельно котлеты отдельно.
Z>>Я твой сценарий вообще к nemerle применить не могу, ты расскажи, что по твоему должен делать Vlad2 и как? Z>>Например вот такой фикс бага: http://code.google.com/p/nemerle/source/detail?r=9646 A>Прежде чем ответить, я хочу уточнить роли. VladD2 мейнтейнер, а hardcase случайная личность со стороны?
Да, так.
A>Прости, но описанный тобой процесс "всё через веб" не позволяет как-либо контроллировать качество предлагаемых патчей.
Ты что-то путаешь, я такой процесс не описывал. В гитхабе процесс "можно через веб, можно в локальном репо". А вот ты предлагаешь "все через локальный репо, а патчи присылайте мне по email".
Делать code review в списках рассылки как-то странно, я сильно удивлюсь, если кто-то будет их делать. А вот с удобным вебинтерфейсом гуглкода люди делают.
Здравствуйте, Ziaw, Вы писали:
A>>Компилировать, запускать, тестировать (unit, performance), анализировать возможные последствия. Performance тоже важен. Если с вижу хорошая фича затормозит PEG парсер в 20 раз, совершенно неочевидным способом, то что делать? Ой, revert, ой, извините? Z>Если на что-то не сделан автотест рано или поздно ручное тестирование слажает. Ой, revert, ой, извините тоже вполне нормальный сценарий в транке.
А как ты хочешь делать автотест на патч, если ты мерджишь через веб? В итоге у тебя будет в мастере непонятно что, которые может пройдёт тесты, а может и нет. Тесты после коммита просто страховка. Разработчик должен их выполнять сам до коммита.
A>>Потому что мейнтейнер имеет доступ до других патчей, да и, сюрприз-сюрприз, сам что-то делает. А на сервер не выкладывает промежуточные, не рабочие версии. У тебя не бывало, чтобы ты делал локальный коммит для фиксации этапа задачи? Этап пушить нельзя, только всю задачу, иначе на сервере будут неработающие исходники. Z>И зачем применять патчи в неработающие исходники? Мухи отдельно котлеты отдельно.
Не неработающие, а новейшие. Вот присылают тебе патч к активно разработываемой фиче, что ты будешь делать? Вдруг функциональность этого патча уже написана. Или наоборот, выбрано архитектурно решение при котором патч становится бессмысленным? Будешь этот шлак толкать прямо в мастер, а думать при мердже?
Z>>>Я твой сценарий вообще к nemerle применить не могу, ты расскажи, что по твоему должен делать Vlad2 и как? Z>>>Например вот такой фикс бага: http://code.google.com/p/nemerle/source/detail?r=9646 A>>Прежде чем ответить, я хочу уточнить роли. VladD2 мейнтейнер, а hardcase случайная личность со стороны? Z>Да, так.
hardcase делает себе clone, вносит изменения отправляет письмо в группу. В тексте описание, во вложении changeset. Заинтересованные мейнтейнеры мониторящие группу, в данном случае VladD2 применяют этот changeset к своей рабочей копии и смотрят что получится. VladD2 прогоняет какие-то тесты, возможно и ручные. Если это библиотека, то VladD2 может посмотреть как зависимые приложения работают с предлагаемыми изменениями. Кроме того, changeset это несколько комитов, возможно VladD2 захочет применить не все, принять из трёх два, а работу сделанную в третьем переделать на свой лад. На любом из этапов VladD2 или кто-то другой может написать письмо hardcase чтобы уточнить что-либо. Премодерированный VladD2 код публикуется, авторство при этом не теряется. При этом, премодерированный код может публиковаться в ветку unstable, где, уже как второй этап, могут некоторые происходить описанные тобой процессы: просмотр красивого diff в браузере и т.д.
A>>Прости, но описанный тобой процесс "всё через веб" не позволяет как-либо контроллировать качество предлагаемых патчей. Z>Ты что-то путаешь, я такой процесс не описывал. В гитхабе процесс "можно через веб, можно в локальном репо". А вот ты предлагаешь "все через локальный репо, а патчи присылайте мне по email". Z>Делать code review в списках рассылки как-то странно, я сильно удивлюсь, если кто-то будет их делать. А вот с удобным вебинтерфейсом гуглкода люди делают.
Для code review патча от случайной личности со стороны нужен не кворум, один ответственный человек. Ты себе представляешь code review, как какой-то восточный базар, а должны быть концентрические круги доверия к разработчикам. Например, приходит патч, кто-то наименее доверенный проверят форматирование, прогоняет тесты и переносит его в ветку contrib. Кто-то более доверенный из ветки contrib переносит патч в unstable. Это значит что патч н просто проходит базовые проверки, но и мейнтейнеры берут ответсвенность за дальнейшую поддержку его кода. Патч может не пееехать из contrib в unstable, если он сложный и низкоприоритетный. Но общение с незнакомыми личностями только по почте.
Здравствуйте, adontz, Вы писали:
A>А как ты хочешь делать автотест на патч, если ты мерджишь через веб? В итоге у тебя будет в мастере непонятно что, которые может пройдёт тесты, а может и нет. Тесты после коммита просто страховка. Разработчик должен их выполнять сам до коммита.
Если не пройдет — будет
A>Не неработающие, а новейшие. Вот присылают тебе патч к активно разработываемой фиче, что ты будешь делать? Вдруг функциональность этого патча уже написана. Или наоборот, выбрано архитектурно решение при котором патч становится бессмысленным? Будешь этот шлак толкать прямо в мастер, а думать при мердже?
Активно разрабатываемые фичи не нуждаются в сторонних патчах. Их делают люди в теме, обычно они пишут в один репо. Просто делается бранч и комитят в него.
A>hardcase делает себе clone, вносит изменения отправляет письмо в группу. В тексте описание, во вложении changeset. Заинтересованные мейнтейнеры мониторящие группу, в данном случае VladD2 применяют этот changeset к своей рабочей копии и смотрят что получится. VladD2 прогоняет какие-то тесты, возможно и ручные. Если это библиотека, то VladD2 может посмотреть как зависимые приложения работают с предлагаемыми изменениями. Кроме того, changeset это несколько комитов, возможно VladD2 захочет применить не все, принять из трёх два, а работу сделанную в третьем переделать на свой лад. На любом из этапов VladD2 или кто-то другой может написать письмо hardcase чтобы уточнить что-либо. Премодерированный VladD2 код публикуется, авторство при этом не теряется. При этом, премодерированный код может публиковаться в ветку unstable, где, уже как второй этап, могут некоторые происходить описанные тобой процессы: просмотр красивого diff в браузере и т.д.
Очень унылая процедура. Немерле ее не переживет. В конце концов патчи по емейл никто отправлять не запрещает, только врядли кто-то захочет это делать.
A>Для code review патча от случайной личности со стороны нужен не кворум, один ответственный человек.
Кворум тоже нужен. Один человек все не увидит.
A>Ты себе представляешь code review, как какой-то восточный базар, а должны быть концентрические круги доверия к разработчикам. Например, приходит патч, кто-то наименее доверенный проверят форматирование, прогоняет тесты и переносит его в ветку contrib. Кто-то более доверенный из ветки contrib переносит патч в unstable. Это значит что патч н просто проходит базовые проверки, но и мейнтейнеры берут ответсвенность за дальнейшую поддержку его кода. Патч может не пееехать из contrib в unstable, если он сложный и низкоприоритетный. Но общение с незнакомыми личностями только по почте.
Пойми одну вещь, процессы должны подстраиваться под продукт, а никак не наоборот. Ты описал процесс с десятками мейнтейнеров и сотнями разработчиков. Когда nemerle до него дорастет можно будет о нем говорить.
Здравствуйте, BogdanMart, Вы писали:
BM>Ок, как через GitExtensions посмотреть кто какуюстрочку в файле изменил на каком комите (в меркуриале -- Bisect, в СВН -- Blame) или как сделать полнотекстовый поиск по репозиторию (TortoiseHG довольно шустро ищет с главного окна)
Bisect это вообще из другой оперы. Blame в GitExtensions — File Tree -> History -> Blame.
BM>Вообщем в чем преимущества? Я имею в виду не хостинга асамих GitExtensions
В том, что с такими системами как git и mercurial нужно работать не как с каталогом файлов, а как с деревом коммитов. Кстати, разработчики TortoiseHg тоже это начали понимать и вынесли Repositore Explorer из подменю в контектстное меню и переназвали его в Hg Workbench.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Ziaw, Вы писали:
Z>Когда я пытал IT, выяснил, что там можно переключаться с бранча на бранч быстрее (на два клика). Больше преимуществ я не услышал. Меркуриал к юзеру сильно дружелюбнее, гит сделан для гиков.
Потому что ты хотел услышать только то, что хотел услышать. Клиенты меркуриала работают с деревом каталогов. Это приговор всей идее. Работать нужно с деревом коммитов.
Z>Что еще хорошего в Git Extensions? Абсолютно неинтуитивный интерфейс, без бутылки не разберешься.
Здравствуйте, WolfHound, Вы писали:
WH>Более того если это просто опечатка то можно прямо на гитхабе поправить ничего себе не вытягивая.
Это пока не советую. Там косяк какой-то юниксовый. Они во всём файле концы строк так подрехтуют, что он весь будет как одно большое изменение. Хрен потом найдёшь что было исправлено. Хотя может уже и поправили.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, adontz, Вы писали:
A>Это легко делается и в HG без всякого веб-интерфейса, по почте. Там прямо в клиенте можно changeset отправить вложением на какой-нибудь адрес. И это на как раз гораздо лучше, потому что у получателя будет почтовый адрес отправителя. Крайне редко когда патчи применяется как есть. Так же, можно отправлять changeset на адрес почтовой рассылки (тех же google groups). То есть веб интерфейс это круто, а почта не атк круто выглядит, зато гораздо лучше укладывается в бизнес-процесс.
Я уже десяток пул-реквестов обработал на гитхабе. А всё, что приходило по почте как-то руки не дошли. Это я к тому как это всё легко делается.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, adontz, Вы писали:
WH>>Ибо если бы прочитал, то знал бы про Git Extensions. A>Я про них знаю и не из этой темы. Убожество эти ваши Git Extensions.
Убожество — это как раз всевозможные тортилки-расширялки оболочки. Для тулов вроде git и меркуриал нужен интерфейс, в котором в главнмм рабочем окне будет находится дерево коммитов, а не папка с файликами.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, adontz, Вы писали:
A>Пул реквест описанный тут http://help.github.com/pull-requests/ редкое убожество. Убожество он, хотя бы потому, что обитает в вебе.
Рома, опять ты начинаешь размахивать налево и направо своим невежеством.
GitExtensions -> Menu -> Github -> View pull requests -> Fetch and Review. Два клика, чтобы посмотреть и ещё один, чтобы добавить его в репозиторий. Мёржить сразу совсем не обязательно, для нового коммита будет создана ветка, с которой можно будет поработать в любое удобное время.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Я поддержу любое решение относительно CVS и конечно приму участие в технической стороне вопроса, но с одним только условием: пусть это будет последний переезд, ок?
Гарантирую, тебе реально понравится
Если нам не помогут, то мы тоже никого не пощадим.
Побольше бы таких статей. У меня появилось одно очко в пользу гита, если я правильно понял, он умеет делать бранчи не только с комитом, а в любой момент. Так?
Меркуриал этим напрягает, например можно забыть поименовать бранч при комите и он уйдет в default, можно забыть закрыть его при merge и он останется висеть
Здравствуйте, IT, Вы писали:
Z>>Когда я пытал IT, выяснил, что там можно переключаться с бранча на бранч быстрее (на два клика). Больше преимуществ я не услышал. Меркуриал к юзеру сильно дружелюбнее, гит сделан для гиков.
IT>Потому что ты хотел услышать только то, что хотел услышать. Клиенты меркуриала работают с деревом каталогов. Это приговор всей идее. Работать нужно с деревом коммитов.
А ты thg/hgtk log запускал? Я всегда работаю именно с деревом комитов, дерево каталогов не интересно вообще.
Здравствуйте, _Raz_, Вы писали:
BM>>GIT клиент под финдой очень громоздкий и ставить сложно. Отдельно ТОртойзгит, отдельнто сам гит.... бред полный. _R_>Git Extensions
Оно только Win32 или я плохо искал x64?
Help will always be given at Hogwarts to those who ask for it.
Здравствуйте, Ziaw, Вы писали:
Z>Побольше бы таких статей. У меня появилось одно очко в пользу гита, если я правильно понял, он умеет делать бранчи не только с комитом, а в любой момент. Так?
Так. Хоть стотыщпицот бранчей в любом месте дерева коммитов.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Ziaw, Вы писали:
IT>>Потому что ты хотел услышать только то, что хотел услышать. Клиенты меркуриала работают с деревом каталогов. Это приговор всей идее. Работать нужно с деревом коммитов. Z>А ты thg/hgtk log запускал? Я всегда работаю именно с деревом комитов, дерево каталогов не интересно вообще.
Я запускал thg workbench (бывший Repository browser). Он хотя и отрисовывает дерево коммитов, но на назвать это работой с ним пока язык не поворачивается. Но прогресс идёт и это заметно. Когда ребята всё скопируют из GitExtensions, то будет совсем хорошо
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Убожество — это как раз всевозможные тортилки-расширялки оболочки. Для тулов вроде git и меркуриал нужен интерфейс, в котором в главнмм рабочем окне будет находится дерево коммитов, а не папка с файликами.
Здравствуйте, IT, Вы писали:
A>>Пул реквест описанный тут http://help.github.com/pull-requests/ редкое убожество. Убожество он, хотя бы потому, что обитает в вебе. IT>Рома, опять ты начинаешь размахивать налево и направо своим невежеством. IT>GitExtensions -> Menu -> Github -> View pull requests -> Fetch and Review. Два клика, чтобы посмотреть и ещё один, чтобы добавить его в репозиторий. Мёржить сразу совсем не обязательно, для нового коммита будет создана ветка, с которой можно будет поработать в любое удобное время.
Если нам не помогут, то мы тоже никого не пощадим.
