Поигрался я тут с гитхабом.
Впечатления супер.
Гуглокод на его фоне просто УГ.
Во всех смыслах.
Особенно порадовало то что там можно создавать не только отдельных пользователей но и организации.
У каждой организации может быть множество репозиториев.
Внутри организации может быть множество команд.
Один человек может состоять в нескольких командах.
Каждой команде можно раздавать права.
А все по тому что гитхаб в отличии от гуглокода на хотинге проектов деньги зарабатывает.
Бесплатно можно хостить только опенсорс. Но нам другого и не надо.
Здравствуйте, WolfHound, Вы писали:
WH>Поигрался я тут с гитхабом. WH>Впечатления супер. WH>Гуглокод на его фоне просто УГ. WH>Во всех смыслах.
WH>Особенно порадовало то что там можно создавать не только отдельных пользователей но и организации. WH>У каждой организации может быть множество репозиториев. WH>Внутри организации может быть множество команд. WH>Один человек может состоять в нескольких командах. WH>Каждой команде можно раздавать права.
WH>А все по тому что гитхаб в отличии от гуглокода на хотинге проектов деньги зарабатывает. WH>Бесплатно можно хостить только опенсорс. Но нам другого и не надо.
WH>Я уже зарегистрировал вот такую организацию. WH>https://github.com/organizations/NemerleTeam
WH>Тк Н2 еще толком не стартовал, а с СВН нужно по любому слезать то предлагаю переехать на гитхаб.
GIT клиент под финдой очень громоздкий и ставить сложно. Отдельно ТОртойзгит, отдельнто сам гит.... бред полный. А меркуриал удобный и легкий. И зачем нам организации в репозитории?
Здравствуйте, BogdanMart, Вы писали:
BM>GIT клиент под финдой очень громоздкий и ставить сложно. Отдельно ТОртойзгит, отдельнто сам гит.... бред полный.
Git Extensions
Здравствуйте, _Raz_, Вы писали:
BM>>GIT клиент под финдой очень громоздкий и ставить сложно. Отдельно ТОртойзгит, отдельнто сам гит.... бред полный. _R_>Git Extensions
+1 ставиться с пол пинка.
Работает лучше чем клиенты все тортилки вместе взятые.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, BogdanMart, Вы писали:
BM>Какие реальные преимущества оно даст разработке немерле?
СВН это просто гиря на ногах. Тормоза. Бранчи делать геморой. В результате все сидят в одной куче и регулярно случаются факапы.
Меркури система одного класса с GIT но Git Extensions рулит со страшной силой.
Гитхаб гораздо удобнее, чем гуглокод и для "одноразовых" коммитеров и для постоянных разработчиков.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, BogdanMart, Вы писали:
BM>>Какие реальные преимущества оно даст разработке немерле? WH>СВН это просто гиря на ногах. Тормоза. Бранчи делать геморой. В результате все сидят в одной куче и регулярно случаются факапы. WH>Меркури система одного класса с GIT но Git Extensions рулит со страшной силой. WH>Гитхаб гораздо удобнее, чем гуглокод и для "одноразовых" коммитеров и для постоянных разработчиков.
Чем удобнее а-то аргументы не очень пока. (тут на работе начали на меркуриал переезжаьб, потому что круче свн) но вот про гит Хотелось бы узнать чем конкретно он лучше меркуриала, и гитхаб гул кода.
Здравствуйте, BogdanMart, Вы писали:
BM>Чем удобнее а-то аргументы не очень пока. (тут на работе начали на меркуриал переезжаьб, потому что круче свн) но вот про гит Хотелось бы узнать чем конкретно он лучше меркуриала,
Тулзами.
BM>и гитхаб гул кода.
Тем, что позволяет использовать все возможности распределенных систем контроля версий.
Клоны в гуглокоде смех не палочке. Там ничего сделать нельзя.
А тут пришол человек.
Никого не спрашивая сделал форк.
Исправил что захотел.
И одной кнопкой отправил запрос на интеграцию своего творения в основную ветку.
Поддержки команд на гуглокоде тоже нет.
Вот допустим есть несколько репозиториев и нужно дать человеку права на пуш во все эти репозитории. На гитхабе просто добавляем этого человека в команду и все. Что делаем на гуглокоде?
Или есть команда и нужно дать всем этим людям права на еще один репозиторий. На гитхабе просто даем всей команде права на это репозиторий. Что делаем на гуглокоде?
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, BogdanMart, Вы писали:
BM>>Чем удобнее а-то аргументы не очень пока. (тут на работе начали на меркуриал переезжаьб, потому что круче свн) но вот про гит Хотелось бы узнать чем конкретно он лучше меркуриала, WH>Тулзами.
BM>>и гитхаб гул кода. WH>Тем, что позволяет использовать все возможности распределенных систем контроля версий.
WH>Клоны в гуглокоде смех не палочке. Там ничего сделать нельзя. WH>А тут пришол человек. WH>Никого не спрашивая сделал форк. WH>Исправил что захотел. WH>И одной кнопкой отправил запрос на интеграцию своего творения в основную ветку.
WH>Поддержки команд на гуглокоде тоже нет. WH>Вот допустим есть несколько репозиториев и нужно дать человеку права на пуш во все эти репозитории. На гитхабе просто добавляем этого человека в команду и все. Что делаем на гуглокоде? WH>Или есть команда и нужно дать всем этим людям права на еще один репозиторий. На гитхабе просто даем всей команде права на это репозиторий. Что делаем на гуглокоде?
Ну звучит неплохо.
А если использовать в пределах предприятия гит, какие преимущества? (со своим сервером)
P.S. Блин гитхб не позволяет логиниться по openID.. фигово (и пароль им надо из 7 символов,ау меня такй пароль уже к важным сайтам стремно юзать там...)
Здравствуйте, BogdanMart, Вы писали:
BM>Ну звучит неплохо. BM>А если использовать в пределах предприятия гит, какие преимущества? (со своим сервером)
Git Extensions
BM>P.S. Блин гитхб не позволяет логиниться по openID.. фигово (и пароль им надо из 7 символов,ау меня такй пароль уже к важным сайтам стремно юзать там...)
Просто теже логин/пароль используются при работи с гитхабом из самого гита. А туда OpenID не засунуть.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, BogdanMart, Вы писали:
BM>>Ну звучит неплохо. BM>>А если использовать в пределах предприятия гит, какие преимущества? (со своим сервером) WH>Git Extensions
Ну а чем именно он лудше TortoiseHG ?
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, _Raz_, Вы писали:
BM>>>GIT клиент под финдой очень громоздкий и ставить сложно. Отдельно ТОртойзгит, отдельнто сам гит.... бред полный. _R_>>Git Extensions WH>+1 ставиться с пол пинка.
Ох оно и подеблиному кучю вопроссов спрашивает (Тортоиз ХГ просто нест некст и все)
Напимер спрашывает насчет line-ending символов. и что ему отвечать?
Здравствуйте, BogdanMart, Вы писали:
BM>Напимер спрашывает насчет line-ending символов. и что ему отвечать?
А что тебе надо?
Я выбрал третий пункт.
Ибо считаю что версионник не должен своими грязными руками править файлы.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, _Raz_, Вы писали:
_R_>Здравствуйте, BogdanMart, Вы писали:
BM>>GIT клиент под финдой очень громоздкий и ставить сложно. Отдельно ТОртойзгит, отдельнто сам гит.... бред полный. _R_>Git Extensions
Здравствуйте, WolfHound, Вы писали:
WH>Работает лучше чем клиенты все тортилки вместе взятые.
Ок, как через GitExtensions посмотреть кто какуюстрочку в файле изменил на каком комите (в меркуриале -- Bisect, в СВН -- Blame) или как сделать полнотекстовый поиск по репозиторию (TortoiseHG довольно шустро ищет с главного окна)
Кроме того нету интеграции с оболочкой винды (не показывает зеленых светофорчиков и в контекстном меню неляз комитить/смотреттьситорию/блеймить/ревертитть, все только через главное окно), может надо перезагрузить? но оно не просило перезагружать.
Вообщем в чем преимущества? Я имею в виду не хостинга асамих GitExtensions
Есилитак воротит от гугла то есть тот же BitBucket.
Да и интеграция со студией что то глючит:
(во время щелчка выделял и солюшен и файл... и не показывает лампочки, как и в проводнике/тотале)
Здравствуйте, BogdanMart, Вы писали:
BM>Ок, как через GitExtensions посмотреть кто какуюстрочку в файле изменил на каком комите (в меркуриале -- Bisect, в СВН -- Blame)
File history
BM>или как сделать полнотекстовый поиск по репозиторию (TortoiseHG довольно шустро ищет с главного окна)
Никогда не пользовалася.
BM>Кроме того нету интеграции с оболочкой винды (не показывает зеленых светофорчиков и в контекстном меню неляз комитить/смотреттьситорию/блеймить/ревертитть, все только через главное окно), может надо перезагрузить? но оно не просило перезагружать.
А зачем?
BM>Да и интеграция со студией что то глючит: BM> BM>(во время щелчка выделял и солюшен и файл... и не показывает лампочки, как и в проводнике/тотале)
Есть такое.
Нужно проект выделять.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
BM>>Кроме того нету интеграции с оболочкой винды (не показывает зеленых светофорчиков и в контекстном меню неляз комитить/смотреттьситорию/блеймить/ревертитть, все только через главное окно), может надо перезагрузить? но оно не просило перезагружать. WH>А зачем?
Очень удобно. А еще лучше так:
Под Windows лучше использовать Mercurial, потому что гораздо проще начать его использовать. TortoiseHG менее вылизан, чем TortoiseSVN, но всё же вполен приличный клиент. А интеграция с шелом нужна, хотя бы потому что не все файлы могут быть включены в проекты Visual Studio. Да и всякие проблемы лучше/легче разрешать на уровне дерева файлов, а не проектов. Интеграция с Visual Studio опять же не глючит. Причём бесплатный VisualHG работает лучше платного VisualSVN. Я не знаю почему так, но так уже вышло.
А git очень хорош, но не под Windows. Под Windows его придётся долго настраивать чтобы получить тоже самое, что и в Linux. Графический клиент отдельная больная тема. Кроме того, в git вообще нет понятия прав доступа. Это понятно, права доступа всячески противоречат его идеологии. Лучшее, что получится использовать — навесная HTTP аутентификация про существование которой git не будет знать. В mercurial система безопаснисти слабая, как и во всех DVCS, но всё же есть. Да и сам mercurial понимает внешние права доступа.
Что касается репозитория и места его хранения. Гуглкод безусловно отстой. Но практически любой внешний хостинг репозитория по тем или иным причинам будет отстоем.
Как показала моя личная практика, ничего лучше чем свой репозиторий придумать нельзя, потому что абсолютно всё можно сделать именно так как хочется. И сделать это легко, быстро, стандартными документированными средствами. Например, я можно легко (простой конфигурацией, без программирования) прикрутить к репозиторию аутентификацию домена Google Apps или OpenID или ещё что угодно. Давать и отнимать права доступа на ветки и типы файлов(!).
Кроме того важны ещё две вещи: интеграция с тикетами и с билд-системой. Последнее означает в случае Nemerle неободимость Windows сервера. Как эти проблемы поможет решить github, bitbucket, etc? Есть план целостной системы?
Здравствуйте, BogdanMart, Вы писали:
BM>>>Ну звучит неплохо. BM>>>А если использовать в пределах предприятия гит, какие преимущества? (со своим сервером) WH>>Git Extensions BM>Ну а чем именно он лудше TortoiseHG ?
Когда я пытал IT, выяснил, что там можно переключаться с бранча на бранч быстрее (на два клика). Больше преимуществ я не услышал. Меркуриал к юзеру сильно дружелюбнее, гит сделан для гиков.
Что еще хорошего в Git Extensions? Абсолютно неинтуитивный интерфейс, без бутылки не разберешься.
Здравствуйте, adontz, Вы писали:
A>Как показала моя личная практика, ничего лучше чем свой репозиторий придумать нельзя, потому что абсолютно всё можно сделать именно так как хочется. И сделать это легко, быстро, стандартными документированными средствами. Например, я можно легко (простой конфигурацией, без программирования) прикрутить к репозиторию аутентификацию домена Google Apps или OpenID или ещё что угодно. Давать и отнимать права доступа на ветки и типы файлов(!).
Легкий форк и пулреквест сделать как хочется непросто.
Здравствуйте, WolfHound, Вы писали:
WH>Поигрался я тут с гитхабом. WH>Впечатления супер.
Вобщем я уже поднимал этот вопрос, слава богу блаб прошел Гит как CVS мне нравится меньше чем hg, но гитхаб больше чем битбукет.
Не озвученная идея разбить все на проекты мне тоже нравится. Для сборки инсталятора можно сделать отдельный проект в который включить все что нужно как модули.
Здравствуйте, adontz, Вы писали:
A>Под Windows лучше использовать Mercurial, потому что гораздо проще начать его использовать. TortoiseHG менее вылизан, чем TortoiseSVN, но всё же вполен приличный клиент. А интеграция с шелом нужна, хотя бы потому что не все файлы могут быть включены в проекты Visual Studio. Да и всякие проблемы лучше/легче разрешать на уровне дерева файлов, а не проектов. Интеграция с Visual Studio опять же не глючит. Причём бесплатный VisualHG работает лучше платного VisualSVN. Я не знаю почему так, но так уже вышло.
Тему ты конечно не читал.
Ибо если бы прочитал, то знал бы про Git Extensions.
A>А git очень хорош, но не под Windows. Под Windows его придётся долго настраивать чтобы получить тоже самое, что и в Linux. Да вы месье теоретик.
Настройка Git Extensions у меня заняла несколько минут.
A> Графический клиент отдельная больная тема.
Git Extensions очень даже графический.
A>Кроме того, в git вообще нет понятия прав доступа.
Зато github имеет.
A>Что касается репозитория и места его хранения. Гуглкод безусловно отстой. Но практически любой внешний хостинг репозитория по тем или иным причинам будет отстоем.
А ты гитхаб то смотрел?
A>Как показала моя личная практика, ничего лучше чем свой репозиторий придумать нельзя, потому что абсолютно всё можно сделать именно так как хочется. И сделать это легко, быстро, стандартными документированными средствами. Например, я можно легко (простой конфигурацией, без программирования) прикрутить к репозиторию аутентификацию домена Google Apps или OpenID или ещё что угодно. Давать и отнимать права доступа на ветки и типы файлов(!).
Ну и нахрена оно надо?
Оно нахрен не надо.
Особенно проекту с открытым исходным кодом.
Ты пойми, нужен вот такой юзкейс:
Человек нашел баг.
Стянул себе исходники.
Никого, не спрашивая исправил.
И одной кнопкой отправил запрос на интеграцию фикса в основной код.
Более того если это просто опечатка то можно прямо на гитхабе поправить ничего себе не вытягивая.
A>Кроме того важны ещё две вещи: интеграция с тикетами и с билд-системой. Последнее означает в случае Nemerle неободимость Windows сервера. Как эти проблемы поможет решить github, bitbucket, etc? Есть план целостной системы?
Интеграция с тикитами в гитхабе отличная.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, adontz, Вы писали:
A>Как показала моя личная практика, ничего лучше чем свой репозиторий придумать нельзя, потому что абсолютно всё можно сделать именно так как хочется. И сделать это легко, быстро, стандартными документированными средствами. Например, я можно легко (простой конфигурацией, без программирования) прикрутить к репозиторию аутентификацию домена Google Apps или OpenID или ещё что угодно. Давать и отнимать права доступа на ветки и типы файлов(!).
Сначала, хотел сказать, что у меня возникает стойкое ощущение, будто ты на этот форум ты заходишь исключительно ради того, чтобы придумать, чем бы меня занять пока я тут плюю в потолок Но ты прав — с технической т.з. это наиболее гибкое решение. Однако же наиболее затратное по времени, поддержке и отсутствию какого-либо пассивного продвижения, которое имеет место в случае CVS-хостинга.
A>Кроме того важны ещё две вещи: интеграция с тикетами и с билд-системой. Последнее означает в случае Nemerle неободимость Windows сервера. Как эти проблемы поможет решить github, bitbucket, etc? Есть план целостной системы?
Если на github'е etc есть коммит-хуки или любой другой API уведомления об изменениях в репозитории, то ничего более для билд-сервера и не нужно.
Здравствуйте, WolfHound, Вы писали:
WH>Тк Н2 еще толком не стартовал, а с СВН нужно по любому слезать то предлагаю переехать на гитхаб.
Я поддержу любое решение относительно CVS и конечно приму участие в технической стороне вопроса, но с одним только условием: пусть это будет последний переезд, ок?
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Я поддержу любое решение относительно CVS и конечно приму участие в технической стороне вопроса, но с одним только условием: пусть это будет последний переезд, ок?
Сейчас нужно решить стоит вообще переезжать.
Если ты зарегистрируешься на гитхабе я тебя добавлю во владельцы NemerleTeam и ты сам сможешь посмотреть насколько оно целесообразно.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Если ты зарегистрируешься на гитхабе я тебя добавлю во владельцы NemerleTeam и ты сам сможешь посмотреть насколько оно целесообразно.
Здравствуйте, kochetkov.vladimir, Вы писали:
WH>>Если ты зарегистрируешься на гитхабе я тебя добавлю во владельцы NemerleTeam и ты сам сможешь посмотреть насколько оно целесообразно. KV>kochetkov
Добавил.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Ибо если бы прочитал, то знал бы про Git Extensions.
Я про них знаю и не из этой темы. Убожество эти ваши Git Extensions.
WH>Настройка Git Extensions у меня заняла несколько минут.
Настройка TortoiseHG у меня вообще ничего не заняла.
A>> Графический клиент отдельная больная тема. WH>Git Extensions очень даже графический.
Но больной
WH>Ну и нахрена оно надо? WH>Оно нахрен не надо. WH>Особенно проекту с открытым исходным кодом.
Непоследовательное заявление для человека который с восторгом рассказывал про компании и команды.
WH>Ты пойми, нужен вот такой юзкейс: WH>Человек нашел баг. WH>Стянул себе исходники. WH>Никого, не спрашивая исправил. WH>И одной кнопкой отправил запрос на интеграцию фикса в основной код.
Это легко делается и в HG без всякого веб-интерфейса, по почте. Там прямо в клиенте можно changeset отправить вложением на какой-нибудь адрес. И это на как раз гораздо лучше, потому что у получателя будет почтовый адрес отправителя. Крайне редко когда патчи применяется как есть. Так же, можно отправлять changeset на адрес почтовой рассылки (тех же google groups). То есть веб интерфейс это круто, а почта не атк круто выглядит, зато гораздо лучше укладывается в бизнес-процесс.
WH>Более того если это просто опечатка то можно прямо на гитхабе поправить ничего себе не вытягивая.
А это уже очень плохая практика. Исходники надо компилировать, прогонять тесты, а уже потом фиксировать. Такой функцией я бы не гордился, а искал бы где выключить.
WH>Интеграция с тикитами в гитхабе отличная.
Вопрос про билд сервер ты благополучно не заметил.
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Сначала, хотел сказать, что у меня возникает стойкое ощущение, будто ты на этот форум ты заходишь исключительно ради того, чтобы придумать, чем бы меня занять пока я тут плюю в потолок Но ты прав — с технической т.з. это наиболее гибкое решение. Однако же наиболее затратное по времени, поддержке и отсутствию какого-либо пассивного продвижения, которое имеет место в случае CVS-хостинга.
Ты несколько заблуждаешься.
Во-первых, вы не первые и в Интернете до фига руководств по настройке. Я, когда начинал, вообще не умел пользоваться командной строкой Линукса, даже не знал как файл скопировать,как по ssh подключится. Быть может, если бы мне кто-то помогал, я бы всё сделал быстрее, но так как есть, с нуля, у меня заняло в обей сложности около недели чистого времени. Причём я всё уже успел обвещать скриптами, плагинами и т.д. Большая часть скачана из Интернета, опять же.
Во-вторых, не имеет никакого значения что вы ставите, если это обновлять. Да тебе надо обновлять софт самому, на гитхабе или ещё где-то это сделают за тебя. Но писать-то тебя никто не заставляет! Не тнавится трак (он настолько же гибкий, насколько и медленно развивающийся) поставь редмайн. Не нравится редмайн, поставь ТракСтудио. Ждиру дают бесплатно в OpenSource. Ставь что хочешь и интегрируй это между собой, в чём проблема-то?
Здравствуйте, adontz, Вы писали:
A>Я про них знаю и не из этой темы. Убожество эти ваши Git Extensions.
А мне нравится.
A>Настройка TortoiseHG у меня вообще ничего не заняла.
Это не правда.
С ним возьни не меньше чем с Git Extensions
A>Непоследовательное заявление для человека который с восторгом рассказывал про компании и команды.
Я вот про это.
прикрутить к репозиторию аутентификацию домена Google Apps или OpenID или ещё что угодно
Это нахрен не надо.
A>Это легко делается и в HG без всякого веб-интерфейса, по почте.
Ну давай еще патчами работать.
Ну и зачем мне тогда вообще версионник?
A>Вопрос про билд сервер ты благополучно не заметил.
Билд сервер еже есть на RSDN. Дергать за урл гитхаб умеет.
Все остальное делатьется на раз два.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
A>>Настройка TortoiseHG у меня вообще ничего не заняла. WH>Это не правда. WH>С ним возьни не меньше чем с Git Extensions
Тем не менее, я пользуюсь ненастроенным. Нет, вру, я там прописываю server fingerprint, потому что я у меня сертификат за 20 баксов, а не за 400 и TortoiseHG считает его недостаточно доверенным. Но это, думаю, к теме отношения не имеет. В остальном пользуюсь как есть.
WH>Я вот про это. WH>
WH>прикрутить к репозиторию аутентификацию домена Google Apps или OpenID или ещё что угодно
WH>Это нахрен не надо.
Я не зря это написал. Если ли бы ты прочитал тему, то увидел бы такой запрос. А single sign-on вообще добро в чистом виде, а иметь кучу юзернеймов и паролей — зло.
WH>Ну давай еще патчами работать. WH>Ну и зачем мне тогда вообще версионник?
Я детально описал конкретные процессы и почему посылать changeset на почту в конечном итоге правильнее. Хочешь фантики, получай фантики. Любые новые или случайные члены будут писать недостаточно качественный код, который придётся так или иначе премодерировать. Почта даёт тебе возможность начать общение с автором без дополнительных действий, веб-интерфейс — нет. Это удобно.
Здравствуйте, Ziaw, Вы писали:
Z>Вобщем я уже поднимал этот вопрос, слава богу блаб прошел Гит как CVS мне нравится меньше чем hg, но гитхаб больше чем битбукет.
Если таки решат юзать гитхаб, то буду использовать в качестве клиента hg, так как он моет работать с репами ГИТа (по крайней мере так утверждают http://hg-git.github.com/ )
Здравствуйте, Anton Batenev, Вы писали:
AB>"Не было у бабки забот"... так чисто виндовым проектом наступили в чисто линуксовую систему контроля версий. А оно вам надо?
А ты хоть одну чиста виндовую систему контроля версий знаешь?
Да и немерле прекрасно живет под линухом.
А гитхабу вообще всеравно из под какой системы к нему цепляются.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
AB>>"Не было у бабки забот"... так чисто виндовым проектом наступили в чисто линуксовую систему контроля версий. А оно вам надо? WH>А ты хоть одну чиста виндовую систему контроля версий знаешь?
TFS?
WH>Да и немерле прекрасно живет под линухом.
Что-то когда я спрашивал, то было совсем наоборот. Работает в Mono под Windows, а под Linux никто даже не пытается компилировать.
Здравствуйте, adontz, Вы писали:
A>Что-то когда я спрашивал, то было совсем наоборот. Работает в Mono под Windows, а под Linux никто даже не пытается компилировать.
Немерле работает в моно под любой поддерживаемой ОС, но не компилируется из-за бага в моно.
Здравствуйте, adontz, Вы писали:
Z>>Легкий форк и пулреквест сделать как хочется непросто.
A>Можно подробнее?
Легкий форк: человек форкает себе репозитарий прямо на сервере, делает в нем что угодно.
Пулреквест: делает запрос на применение своих правок в оригинальном репозитарии.
Для всего этого нужен удобный вебинтерфейс. Если ручной мердж не требуется — правки вливаются прямо в нем.
Здравствуйте, Ziaw, Вы писали:
Z>Легкий форк: человек форкает себе репозитарий прямо на сервере, делает в нем что угодно.
Какой в этом смысл вообще? Компилировать не получится, запустить не получится, тем более тесты прогнать.
Z>Пулреквест: делает запрос на применение своих правок в оригинальном репозитарии.
В HG это делается отправкой письма, я уже описывал как.
Здравствуйте, adontz, Вы писали:
Z>>Легкий форк: человек форкает себе репозитарий прямо на сервере, делает в нем что угодно.
A>Какой в этом смысл вообще? Компилировать не получится, запустить не получится, тем более тесты прогнать.
Он получает свой клон, изменения в котором видны всем. Посмотри проекты на гитхабе с кучей форков.
Z>>Пулреквест: делает запрос на применение своих правок в оригинальном репозитарии.
A>В HG это делается отправкой письма, я уже описывал как.
Здравствуйте, Ziaw, Вы писали:
Z>>>Легкий форк: человек форкает себе репозитарий прямо на сервере, делает в нем что угодно. A>>Какой в этом смысл вообще? Компилировать не получится, запустить не получится, тем более тесты прогнать. Z>Он получает свой клон, изменения в котором видны всем. Посмотри проекты на гитхабе с кучей форков.
Это форк ради форка, никак не проверенный, возможно даже не компилирующийся. Кому-то всё равно придётся это компилировать, мерджить, прогонять тесты. По твоему описанию это не просто бесполезная, но крайне вредная функция, так как на мейнтейнеров перекладывается больше функций, к тому же, непитичных.
Z>>>Пулреквест: делает запрос на применение своих правок в оригинальном репозитарии. A>>В HG это делается отправкой письма, я уже описывал как. Z>Извини, но это убожество
Хочешь понты, делай через веб, а работоспособный бизнес-процесс делается через почту, чтобы ты об этом ни думал. Пулреквест это функция, а не бизнес-процесс. Мыслить надо не кнопочками на страничках, а процессами. Патч должен быть рассмотрен, обсуждён и только потом принят. Пулреквест тебе этого не даёт, почта даёт. После твоего пул-реквеста всё равно надо будет где-то обсуждать патч. Убожество это функция ради функции, оторванная от жизненных потребностей.
KV>Но ты прав — с технической т.з. это наиболее гибкое решение. Однако же наиболее затратное по времени, поддержке и отсутствию какого-либо пассивного продвижения, которое имеет место в случае CVS-хостинга.
Гитхаб сам по себе опенсорсный. Его можно поставить на свой сервер и докрутить, только какой в этом смысл? Разве что одеть его в твой дизайн. А что, мысль! Как минимум вики, подсветка кода, блог, тикеты будут готовые.
KV>Если на github'е etc есть коммит-хуки или любой другой API уведомления об изменениях в репозитории, то ничего более для билд-сервера и не нужно.
Здравствуйте, adontz, Вы писали:
A>Хочешь понты, делай через веб, а работоспособный бизнес-процесс делается через почту, чтобы ты об этом ни думал. Пулреквест это функция, а не бизнес-процесс. Мыслить надо не кнопочками на страничках, а процессами. Патч должен быть рассмотрен, обсуждён и только потом принят. Пулреквест тебе этого не даёт, почта даёт. После твоего пул-реквеста всё равно надо будет где-то обсуждать патч. Убожество это функция ради функции, оторванная от жизненных потребностей.
Ссылку с описанием того что есть в пуллреквестах ты похоже не читал.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, adontz, Вы писали:
A>Хочешь понты, делай через веб, а работоспособный бизнес-процесс делается через почту, чтобы ты об этом ни думал. Пулреквест это функция, а не бизнес-процесс. Мыслить надо не кнопочками на страничках, а процессами. Патч должен быть рассмотрен, обсуждён и только потом принят. Пулреквест тебе этого не даёт, почта даёт. После твоего пул-реквеста всё равно надо будет где-то обсуждать патч. Убожество это функция ради функции, оторванная от жизненных потребностей.
Здравствуйте, WolfHound, Вы писали:
A>>Хочешь понты, делай через веб, а работоспособный бизнес-процесс делается через почту, чтобы ты об этом ни думал. Пулреквест это функция, а не бизнес-процесс. Мыслить надо не кнопочками на страничках, а процессами. Патч должен быть рассмотрен, обсуждён и только потом принят. Пулреквест тебе этого не даёт, почта даёт. После твоего пул-реквеста всё равно надо будет где-то обсуждать патч. Убожество это функция ради функции, оторванная от жизненных потребностей. WH>Ссылку с описанием того что есть в пуллреквестах ты похоже не читал.
Андрей, вместо того чтобы сказать что-то по существу, а точнее когда тебе нечего сказать по существу, ты любишь соскакивать с темы и заявлять что кто-то что-то не читал.
Пул реквест описанный тут http://help.github.com/pull-requests/ редкое убожество. Убожество он, хотя бы потому, что обитает в вебе. Исходный код надо смотреть не в браузере, а в редакторе исходного кода. С меркуриалом я получаю по почте changeset, применяю его к своему репозиторию и смотрю что получилось, что как работает, вижу работающую программу. Причём не в контексте master, а в контексте своей локальной копии. Если новый патч не совместим с моими, ещё не опубликованными изменениями иил дублирует их, полностью или частично, то лкально я это увижу, а в браузере, естественно, нет. На кой ляд спользовать DVCS и приэтом делать обмен changeset'ами централизованным? Возьми тогда SVN, там всё на сервере.
Здравствуйте, adontz, Вы писали:
Z>>Почта самое удобное место пообсуждать патч, ага.
A>mailing list с веб интерфейсом отличается от древовидного форума, только названием.
Здравствуйте, adontz, Вы писали:
A>Пул реквест описанный тут http://help.github.com/pull-requests/ редкое убожество. Убожество он, хотя бы потому, что обитает в вебе. Исходный код надо смотреть не в браузере, а в редакторе исходного кода. С меркуриалом я получаю по почте changeset, применяю его к своему репозиторию и смотрю что получилось, что как работает, вижу работающую программу. Причём не в контексте master, а в контексте своей локальной копии. Если новый патч не совместим с моими, ещё не опубликованными изменениями иил дублирует их, полностью или частично, то лкально я это увижу, а в браузере, естественно, нет. На кой ляд спользовать DVCS и приэтом делать обмен changeset'ами централизованным? Возьми тогда SVN, там всё на сервере.
Весь твой сценарий делается точно так же, только без почты. Пулишь этот реквест себе локально и делаешь то же самое. Если что-то не так — код можно прокоментировать прямо в реквесте, по любой строке. Как ты будешь делать это по почте, я не знаю. Вообще странный сценарий для опенсорса.
А вот мелкие фиксы мерджатся онлайн легко и непринужденно. Это то, для чего сейчас дают доступ к svn всем желающим. Извини, но "смотрю что получилось, что как работает, вижу работающую программу" не для nemerle сценарий. Вот "смотрю на правку, смотрю на ее тесты", хоть оналайн, хоть в собственном репо, вполне рабочий.
Здравствуйте, Ziaw, Вы писали:
Z>Весь твой сценарий делается точно так же, только без почты. Пулишь этот реквест себе локально и делаешь то же самое. Если что-то не так — код можно прокоментировать прямо в реквесте, по любой строке. Как ты будешь делать это по почте, я не знаю. Вообще странный сценарий для опенсорса.
Я это не буду делать на почте, я это буду делать локально. Применю changeset, импортирую его в свой репозиторий и посмотрю разницу со своим текущим кодом, то что на вебе принципиально сделать не получится. Ты правда не понимаешь, почему мейнтейнеру важно смотреть разницу с локальной версией, а не с той, что на сервере?
Z>А вот мелкие фиксы мерджатся онлайн легко и непринужденно. Это то, для чего сейчас дают доступ к svn всем желающим. Извини, но "смотрю что получилось, что как работает, вижу работающую программу" не для nemerle сценарий. Вот "смотрю на правку, смотрю на ее тесты", хоть оналайн, хоть в собственном репо, вполне рабочий.
Здравствуйте, Ziaw, Вы писали:
Z>>>Почта самое удобное место пообсуждать патч, ага. A>>mailing list с веб интерфейсом отличается от древовидного форума, только названием. Z>Покажи мне опенсорс проект с такими патчами.
А причём тут open source вообще? Блин, ты как Wolfhound, нечего сказать по существу и прыгаешь с темы.
Что касается твоего нелепого вопроса, мне вот никогда не нужно было стадо с которым ходить, так что вопрос "В котором из FOSS проектов принято обменивается патчами по почте" меня никогда не волновал. Ищи сам, гугл в помощь. Впрочем, я тебе подскажу. Линус "Наше Всё" Торвальдс, в своей знаменитой презентации гита описывал такой сценарий. Так что это даже не специфично для меркуриала, просто в него всё встроено из коробки.
Здравствуйте, adontz, Вы писали:
Z>>Покажи мне опенсорс проект с такими патчами.
A>А причём тут open source вообще? Блин, ты как Wolfhound, нечего сказать по существу и прыгаешь с темы.
Драсьте. Ты тут опенсорсному проекту даешь советы по модели совместной разработки, а потом спрашиваешь, причем тут opensource?
Практически все системы контроля версий умеют обмениваться патчами по почте. Это не значит, что твой процесс подходит всем.
Здравствуйте, adontz, Вы писали:
Z>>Весь твой сценарий делается точно так же, только без почты. Пулишь этот реквест себе локально и делаешь то же самое. Если что-то не так — код можно прокоментировать прямо в реквесте, по любой строке. Как ты будешь делать это по почте, я не знаю. Вообще странный сценарий для опенсорса.
A>Я это не буду делать на почте, я это буду делать локально.
Делать ревью правок с коментариями?
A>Применю changeset, импортирую его в свой репозиторий и посмотрю разницу со своим текущим кодом, то что на вебе принципиально сделать не получится. Ты правда не понимаешь, почему мейнтейнеру важно смотреть разницу с локальной версией, а не с той, что на сервере?
Не понимаю, откуда у мейнтейнера версия отличная от версии на сервере, у него какой-то приватный форк?
А ты правда не понимаешь, что то, что не получится в вебе, можно сделать локально, только удобнее чем патчами через SMTP?
Z>>А вот мелкие фиксы мерджатся онлайн легко и непринужденно. Это то, для чего сейчас дают доступ к svn всем желающим. Извини, но "смотрю что получилось, что как работает, вижу работающую программу" не для nemerle сценарий. Вот "смотрю на правку, смотрю на ее тесты", хоть оналайн, хоть в собственном репо, вполне рабочий.
A>Ты сценарии перепутал.
Я твой сценарий вообще к nemerle применить не могу, ты расскажи, что по твоему должен делать Vlad2 и как?
Здравствуйте, Ziaw, Вы писали:
A>>Я это не буду делать на почте, я это буду делать локально. Z>Делать ревью правок с коментариями?
Компилировать, запускать, тестировать (unit, performance), анализировать возможные последствия. Performance тоже важен. Если с вижу хорошая фича затормозит PEG парсер в 20 раз, совершенно неочевидным способом, то что делать? Ой, revert, ой, извините?
A>>Применю changeset, импортирую его в свой репозиторий и посмотрю разницу со своим текущим кодом, то что на вебе принципиально сделать не получится. Ты правда не понимаешь, почему мейнтейнеру важно смотреть разницу с локальной версией, а не с той, что на сервере? Z>Не понимаю, откуда у мейнтейнера версия отличная от версии на сервере, у него какой-то приватный форк?
Потому что мейнтейнер имеет доступ до других патчей, да и, сюрприз-сюрприз, сам что-то делает. А на сервер не выкладывает промежуточные, не рабочие версии. У тебя не бывало, чтобы ты делал локальный коммит для фиксации этапа задачи? Этап пушить нельзя, только всю задачу, иначе на сервере будут неработающие исходники.
Z>Я твой сценарий вообще к nemerle применить не могу, ты расскажи, что по твоему должен делать Vlad2 и как? Z>Например вот такой фикс бага: http://code.google.com/p/nemerle/source/detail?r=9646
Прежде чем ответить, я хочу уточнить роли. VladD2 мейнтейнер, а hardcase случайная личность со стороны?
Здравствуйте, 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. Два клика, чтобы посмотреть и ещё один, чтобы добавить его в репозиторий. Мёржить сразу совсем не обязательно, для нового коммита будет создана ветка, с которой можно будет поработать в любое удобное время.
Здравствуйте, adontz, Вы писали:
IT>>Рома, опять ты начинаешь размахивать налево и направо своим невежеством.
A>Не-не-не, мы обсуждаем не технические возможности, а процесс! Вот тут товарищь явно пишет http://www.rsdn.ru/forum/nemerle/4265342.1.aspx
Здравствуйте, adontz, Вы писали:
IT>>Убожество — это как раз всевозможные тортилки-расширялки оболочки. Для тулов вроде git и меркуриал нужен интерфейс, в котором в главнмм рабочем окне будет находится дерево коммитов, а не папка с файликами. A>В HG есть оба
Для git тоже есть TortoiseGit, только это всё не серьёзно.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, _FRED_, Вы писали:
BM>>>GIT клиент под финдой очень громоздкий и ставить сложно. Отдельно ТОртойзгит, отдельнто сам гит.... бред полный. _R_>>Git Extensions
_FR>Оно только Win32 или я плохо искал x64?
Для обеих сразу.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
BM>>>>GIT клиент под финдой очень громоздкий и ставить сложно. Отдельно ТОртойзгит, отдельнто сам гит.... бред полный. _R_>>>Git Extensions _FR>>Оно только Win32 или я плохо искал x64?
IT>Для обеих сразу.
Что-то у меня ничего не спрашивая пытается поставиться в Program Files (x86)
Кстати, а на сайте-то хаба можно подсветку к исходникам на немерле прикрутить?
Help will always be given at Hogwarts to those who ask for it.
Здравствуйте, _FRED_, Вы писали:
_FR>Кстати, а на сайте-то хаба можно подсветку к исходникам на немерле прикрутить?
Они используют http://pygments.org/ и пишут, что если законтрибутишь синтаксис своего языка в пигменты, то они добавят его в качестве поддерживаемого на github.
Легкий форк в вебе, пулреквест тоже доступен для ревью в вебе. Даже простой merge, доступен в вебе. Ты же читаешь это как "единственно возможный процесс". Хотя я не раз писал, что все можно сделать и в локальном репозитории.
Здравствуйте, Ziaw, Вы писали:
Z>Что не так написано? Z>Легкий форк в вебе, пулреквест тоже доступен для ревью в вебе. Даже простой merge, доступен в вебе. Ты же читаешь это как "единственно возможный процесс". Хотя я не раз писал, что все можно сделать и в локальном репозитории.
Я прочитал это не как "единственно возможный", а как "наиболее приемлемый".
Здравствуйте, adontz, Вы писали:
Z>>Легкий форк в вебе, пулреквест тоже доступен для ревью в вебе. Даже простой merge, доступен в вебе. Ты же читаешь это как "единственно возможный процесс". Хотя я не раз писал, что все можно сделать и в локальном репозитории.
A>Я прочитал это не как "единственно возможный", а как "наиболее приемлемый".
Я же писал про простой merge. Он вполне приемлем, только к сожалению, как здесь написали, криво работает.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, Ziaw, Вы писали:
Z>>Побольше бы таких статей. У меня появилось одно очко в пользу гита, если я правильно понял, он умеет делать бранчи не только с комитом, а в любой момент. Так?
IT>Так. Хоть стотыщпицот бранчей в любом месте дерева коммитов.
то есть например сделал я commit1 , потом на него commit2. После этого я могу сказать, что commit1 — это новая ветка new_branch — и commit2 — тоже в эту ветку попадет, так??
Здравствуйте, Jack128, Вы писали:
J>то есть например сделал я commit1 ,
Сделал:
commit1 X branch1
J>потом на него commit2.
commit2, ветка-метка branch1 переехала:
commit2 X branch1
|
commit1 X
J>После этого я могу сказать, что commit1 — это новая ветка new_branch —
Приклеиваем новую метку new_branch к commit1
commit2 X branch1
|
commit1 X new_branch
J>и commit2 — тоже в эту ветку попадет, так??
Попадает?
Мне не очень нравится термин branch, потому что он только запутывает. У нас есть дерево коммитов. В этом дереве может вообще не быть ни одного branch, даже master. Это просто дерево коммитов, связанных между собой историей. Ветку (метку) можно прилепить к любому месту дерева коммитов. Коммит в эту ветку создаст новый коммит и только тогда у нас появится ответвление от этого места.
commit3 X new_branch
|
commit2 X | branch1
|/
commit1 X
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Они используют http://pygments.org/ и пишут, что если законтрибутишь синтаксис своего языка в пигменты, то они добавят его в качестве поддерживаемого на github.
Похоже эта хрень позволяет организовать вложенные лексеры (состояния). Так что можно будет нашу рекурсивную стркоу правильно подсвечивать.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, IT, Вы писали:
IT>Потому что ты хотел услышать только то, что хотел услышать. Клиенты меркуриала работают с деревом каталогов.
Это чушь. Современный клиент ни чем не отличается от того что ты в своей статье описал. И работа там ведется именно с репозиторием в целом.
IT>Это приговор всей идее. Работать нужно с деревом коммитов.
Похоже что это ты пытаешься видеть то что хочешь и не видеть остального.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
WH>>Гитхаб гораздо удобнее, чем гуглокод и для "одноразовых" коммитеров и для постоянных разработчиков. VD>С первым согласен, а вот что удобного для постоянных разработчиков?
Пуллреквесты. И то что с ними можно прямо из Git Extensions работать.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, VladD2, Вы писали:
IT>>Потому что ты хотел услышать только то, что хотел услышать. Клиенты меркуриала работают с деревом каталогов. VD>Это чушь. Современный клиент ни чем не отличается от того что ты в своей статье описал. И работа там ведется именно с репозиторием в целом.
Современный клиент — это май месяц, а статья пылится в закромах редакции с зимы. С тех пор в современном клиенте кое-что было действительно улучшено, он переехал из подменю в контекстное меню и стал называться workbench, а не browser. Направление верное, но до GitExtensions ещё как в известной позе до Парижа.
IT>>Это приговор всей идее. Работать нужно с деревом коммитов. VD>Похоже что это ты пытаешься видеть то что хочешь и не видеть остального.
Чего остального? Дерева каталогов? Или ты о чём-то о своём?
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, WolfHound, Вы писали:
WH>>>Гитхаб гораздо удобнее, чем гуглокод и для "одноразовых" коммитеров и для постоянных разработчиков. VD>>С первым согласен, а вот что удобного для постоянных разработчиков? WH>Пуллреквесты. И то что с ними можно прямо из Git Extensions работать.
Это как раз для одиночек надо.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, VladD2, Вы писали:
IT>>>Потому что ты хотел услышать только то, что хотел услышать. Клиенты меркуриала работают с деревом каталогов. VD>>Это чушь. Современный клиент ни чем не отличается от того что ты в своей статье описал. И работа там ведется именно с репозиторием в целом.
IT>Современный клиент — это май месяц,
Какая разница? Ты же сейчас заявления делаешь. Пойми я не против тебя и твоего мнения. Но выдавать свои домыслы за рельность не стоит. Сразу отношение ко всем твоим утверждениям становится недоверительным.
IT>Направление верное, но до GitExtensions ещё как в известной позе до Парижа.
Возможно. Но это не осбуждается. Обсуждаются твои абсурдные утверждения про "работу с каталогами, а не с деревом комитов".
IT>Чего остального? Дерева каталогов? Или ты о чём-то о своём?
У тебя реальный пунктик на этом дереве. Где ты его узрел я даже не знаю. Кончай выдумывать. Оставь то о чем говришь и погляди сам. Там именно что идет работа с деревом комитов.
И перестать по сто раз повторять одно и то же. Уже достало же. Ну, очевидно же что ты фигню говоришь.
Единственное приемущество гита, как я понимаю — это наличии на гитхабе правильно реализованных клонов (форков) которые позволяют добавлять в клоны (форки) других людей и облегчают запросы на слияние с основным репозиторием. Ну, еще возможно клиент более интуитивный (хотя тут звучат и другие мнения). А вот про дерево каких-то там каталогов — это просто высосанный из пальца гон.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>С первым согласен, а вот что удобного для постоянных разработчиков?
Я тут тоже поковырял гит. Что полезного по сравнению с меркуриалом: нормальные бранчи, чтобы открыть бранч не нужен комит. В меркуриале можно свести бранч с "транком", но не закрыть (просто забыть галочку). Бранч повиснет навечно (по крайней мере я не нашел как это обойти).
Форки и пулреквесты тоже достаточно приятные фичи.
Еще есть удобная вещь, cherry picking, когда комиты из одной ветки применяешь к другой, без слияния. Может быть незменимо во многих сценариях. В меркуриале вроде есть плагины для этого, я не искал.
Здравствуйте, VladD2, Вы писали:
VD>Какая разница? Ты же сейчас заявления делаешь. Пойми я не против тебя и твоего мнения. Но выдавать свои домыслы за рельность не стоит. Сразу отношение ко всем твоим утверждениям становится недоверительным.
Теперь я не въезжаю о чём ты Какие домыслы, какая реальность?
IT>>Направление верное, но до GitExtensions ещё как в известной позе до Парижа. VD>Возможно. Но это не осбуждается. Обсуждаются твои абсурдные утверждения про "работу с каталогами, а не с деревом комитов".
Мы вообще о чём? Если о TortoiseHg, то ты должен быть в курсе, что это расширение оболочки виндоуз, сделанное по образу и подобию TortiesSVN. Правильно?
Если нам не помогут, то мы тоже никого не пощадим.
Re[5]: github vs googlecode
От:
Аноним
Дата:
12.05.11 20:21
Оценка:
Здравствуйте, BogdanMart, Вы писали:
BM>Да и интеграция со студией что то глючит: BM> BM>(во время щелчка выделял и солюшен и файл... и не показывает лампочки, как и в проводнике/тотале)
Проект находится в стадии развития, там ещё шероховатости. Заведите задачку, обязательно поправим.
Здравствуйте, VladD2, Вы писали:
WH>>Гитхаб гораздо удобнее, чем гуглокод и для "одноразовых" коммитеров и для постоянных разработчиков. VD>С первым согласен, а вот что удобного для постоянных разработчиков?
Это работает в обе стороны. Получил уведомление о Pull Request, забрал в отдельный коммит, Pull Request автоматически закрылся. Дальше можно с этим комитом делать всё, что угодно, он уже в репозитории.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Мы вообще о чём? Если о TortoiseHg, то ты должен быть в курсе, что это расширение оболочки виндоуз, сделанное по образу и подобию TortiesSVN. Правильно?
Нет, это набор инструментов, примерно такой-же как git extensions. Так же как gitex, hgtk имеет cmdline интерфейс. Удобно работать как из фара, так и кнопками в студии. Хотя интеграция в эксплорер есть, я ей не пользуюсь вообще.
Здравствуйте, Ziaw, Вы писали:
IT>>Мы вообще о чём? Если о TortoiseHg, то ты должен быть в курсе, что это расширение оболочки виндоуз, сделанное по образу и подобию TortiesSVN. Правильно? Z>Нет, это набор инструментов, примерно такой-же как git extensions. Так же как gitex, hgtk имеет cmdline интерфейс. Удобно работать как из фара, так и кнопками в студии. Хотя интеграция в эксплорер есть, я ей не пользуюсь вообще.
Вот! О чём я и говорю. Раз не пользуюсь, то зачем оно вообще нужно? Не проще ли вообще иметь отдельную утилиту?
Да и таким набором инструментов оно стало не так давно. Буквально с последней версией.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Вот! О чём я и говорю. Раз не пользуюсь, то зачем оно вообще нужно? Не проще ли вообще иметь отдельную утилиту?
Ещё раз напоминаю, что не все файлы могут быть (должны быть) добавлены в солюшены VS. Откуда-то добавлять надо. Удобнее GUI.
IT>Да и таким набором инструментов оно стало не так давно. Буквально с последней версией.
Здравствуйте, adontz, Вы писали:
IT>>Вот! О чём я и говорю. Раз не пользуюсь, то зачем оно вообще нужно? Не проще ли вообще иметь отдельную утилиту? A>Ещё раз напоминаю, что не все файлы могут быть (должны быть) добавлены в солюшены VS. Откуда-то добавлять надо. Удобнее GUI.
Точно. Как раз GitExtensions и есть такое GUI.
IT>>Да и таким набором инструментов оно стало не так давно. Буквально с последней версией. A>Там всего-то две версии, аргумент слабый
А как ты версии считаешь?
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>>>Да и таким набором инструментов оно стало не так давно. Буквально с последней версией. A>>Там всего-то две версии, аргумент слабый IT>А как ты версии считаешь?
Смотрю что написано в диалоге About TortoiseHg. Там написано 2.0.
Здравствуйте, IT, Вы писали:
A>>Смотрю что написано в диалоге About TortoiseHg. Там написано 2.0. IT>А у меня написано 2.0.3. Это получается 203-я версия? А до этого была версия 1.1.9.1. Это 1191-я версия?
Мне придётся объяснять тебе структуру общепринятого формата численного обозначения версий major.minor.build.revision или ты избавишь меня от порции своего непристойного поведения?
Здравствуйте, adontz, Вы писали:
A>Мне придётся объяснять тебе структуру общепринятого формата численного обозначения версий major.minor.build.revision или ты избавишь меня от порции своего непристойного поведения?
Избавлю. Сегодня вышел релиз Немерла, поэтому я всем всё прощаю
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, WolfHound, Вы писали:
WH>Тк Н2 еще толком не стартовал, а с СВН нужно по любому слезать то предлагаю переехать на гитхаб.
Ты предлагаешь перевоз только Н2 или обоих проектов?
Я так думаю, что после релиза Н1 надо делать две ветки,
багфиксы 1.0
новые фичи и багфиксы 1.1
Вот для этого гит будет рулить со страшной силой, я даже не представляю толком как это вести в svn.
Если мигрировать, то надо сразу понять объем затрат, это:
миграция репозитария и поддержка какое-то время svn на гуглкоде (просто периодические пушить туда изменения). Это не большая проблема, ее уже сделал один парень, можно попросить у него репо (я не уверен, что обычный клон сможет пушить обратно в svn)
миграция вики, вобщем-то нечего мигрировать
миграция issues, тут основная засада, но их как раз вполне можно оставить на гуглкоде, пуш туда из гита будет закрывать issues. Это конечно не совсем красиво, но снимает 90% трудозатрат по переезду.
Так вот, если отмирорить код и обновлять по хуку svn, то переезд могут даже не заметить люди не делающие комиты. Вот комитерам придется всем переползти на гит, ибо сводить ветку в svn и в гит в двустороннем порядке будет совсем невесело, скрипт ляжет на первом конфликте.
Останется одна проблема, билдскрипты берущие версию из свн. Но если svn мы оставляем, то выкладывать билды можно и из него. Либо просто считать ревизии и их количество принимать за revision number, либо перейти на major.minor.build. Вобщем выкрутиться можно, я бы даже занялся этим, если это станет единственной проблемой для переезда.
Кстати. Организацию нужно было назвать nemerle. Вообще желательно посмотреть как всё устроено у людей. Например, в mono.
А ещё лучше всё-таки придумать языку нормальное название и им назвать организацию и репозиторий для следующей версии языка. А в репозиторий nemerle положить текущую версию.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Кстати. Организацию нужно было назвать nemerle. Вообще желательно посмотреть как всё устроено у людей. Например, в mono.
Можно и так назвать. Сейчас там ничего не происходит так что можно прямо сейчас все грохнуть и переделать.
IT>А ещё лучше всё-таки придумать языку нормальное название и им назвать организацию и репозиторий для следующей версии языка. А в репозиторий nemerle положить текущую версию.
А чем nemerle плох?
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Ziaw, Вы писали:
Z>Так вот, если отмирорить код и обновлять по хуку svn, то переезд могут даже не заметить люди не делающие комиты. Вот комитерам придется всем переползти на гит, ибо сводить ветку в svn и в гит в двустороннем порядке будет совсем невесело, скрипт ляжет на первом конфликте.
Не надо ничего миррорить. Это лишний никому не нужный гомор, к тому же это дело местами подглюкивает. На сайте нужно дать объявление, что код переехал и всё.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
Z>>Так вот, если отмирорить код и обновлять по хуку svn, то переезд могут даже не заметить люди не делающие комиты. Вот комитерам придется всем переползти на гит, ибо сводить ветку в svn и в гит в двустороннем порядке будет совсем невесело, скрипт ляжет на первом конфликте.
IT>Не надо ничего миррорить. Это лишний никому не нужный гомор, к тому же это дело местами подглюкивает. На сайте нужно дать объявление, что код переехал и всё.
По хорошему да. Только тогда надо тащить issues и переделывать процесс именования версий. Впрочем его все равно переделывать надо. Я просто предложил сценарий, который, ничего не ломая, позволяет быстро попробовать гит.
Здравствуйте, WolfHound, Вы писали:
IT>>А ещё лучше всё-таки придумать языку нормальное название и им назвать организацию и репозиторий для следующей версии языка. А в репозиторий nemerle положить текущую версию. WH>А чем nemerle плох?
Как-то несерьёзны все эти сказочные гарри поттеры. К тому же выправление существующих косяков в языке безусловно приведёт к несовместимости первой и последующих версий, а с новым названием — это новый язык. Немерле должен остаться в истории как прототип для нового языка, коим он по сути и является.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Как-то несерьёзны все эти сказочные гарри поттеры. К тому же выправление существующих косяков в языке безусловно приведёт к несовместимости первой и последующих версий, а с новым названием — это новый язык. Немерле должен остаться в истории как прототип для нового языка, коим он по сути и является.
И какие будут предложения?
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
IT>>Как-то несерьёзны все эти сказочные гарри поттеры. К тому же выправление существующих косяков в языке безусловно приведёт к несовместимости первой и последующих версий, а с новым названием — это новый язык. Немерле должен остаться в истории как прототип для нового языка, коим он по сути и является. WH>И какие будут предложения?
Предложения чего?
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, WolfHound, Вы писали:
WH>>Названия. Кто тут предлагал язык переименовать?
IT>Я уже своё предложение озвучил — Next#, сокращённо можно N#.
Не надо вот это вот!!! Диезы всякие приплетать... Хорошее название было вообщем.
Здравствуйте, WolfHound, Вы писали:
WH>Я уже зарегистрировал вот такую организацию. WH>https://github.com/organizations/NemerleTeam
WH>Тк Н2 еще толком не стартовал, а с СВН нужно по любому слезать то предлагаю переехать на гитхаб.
А что по поводу http://bitbucket.org ? Это позволит вам использовать все Mercurial, т.е. быть совместимыми с репозитариями на googlecode и на http://codeplex.com (где основная масса .NET проектов).
Здравствуйте, sergey_shandar, Вы писали:
_>А что по поводу http://bitbucket.org ? Это позволит вам использовать все Mercurial, т.е. быть совместимыми с репозитариями на googlecode и на http://codeplex.com (где основная масса .NET проектов).
А зачем быть совместимыми? Какие сценарии это покроет?
Вообще гит все же несколько более удобная система в плане бранчей. А гитхаб в плане форков и пулреквестов. Вот, например, я сделал форк https://bitbucket.org/birkenfeld/pygments-main и сделал пулреквест. В гитхабе реквест был бы виден, его можно было бы смотреть, за него можно было бы проголосовать. А тут как в воду канул. Это просто приватная мессага комитерам, с урлом моего форка.
IT>Как-то несерьёзны все эти сказочные гарри поттеры. К тому же выправление существующих косяков в языке безусловно приведёт к несовместимости первой и последующих версий, а с новым названием — это новый язык. Немерле должен остаться в истории как прототип для нового языка, коим он по сути и является.
Не стоит переименовывать. Nemerle уже в принципе известен, имеет какую-то популярность, гугл уже давно перестал предлагать "did you mean ...", и на первой странице по этому ключевому слову всё только о нём в конце концов. Взяться за раскрутку нового названия — это впустую тратить силы и время. PHP вон вообще безумное название, и ничё, живой Microsoft свой Visual Basic тоже держит прочно, несмотря на то что он уже давно не тот "basic", и совсем разный до .NET и после.
Здравствуйте, hi_octane, Вы писали:
_>Не стоит переименовывать. Nemerle уже в принципе известен, имеет какую-то популярность, гугл уже давно перестал предлагать "did you mean ...", и на первой странице по этому ключевому слову всё только о нём в конце концов. Взяться за раскрутку нового названия — это впустую тратить силы и время. PHP вон вообще безумное название, и ничё, живой Microsoft свой Visual Basic тоже держит прочно, несмотря на то что он уже давно не тот "basic", и совсем разный до .NET и после.
Ага. Проблемы с notabilty нафиг не нужны. Вдобавок будет складываться впечатление, что nemerle брошен, а разработчики кинулись делать другой язык. Где гарантия, что они и этот через несколько лет не бросят?
Здравствуйте, sergey_shandar, Вы писали:
_>А что по поводу http://bitbucket.org ? Это позволит вам использовать все Mercurial, т.е. быть совместимыми с репозитариями на googlecode и на http://codeplex.com (где основная масса .NET проектов).
codeplex.com == УГ. В нем опять же придется использовать СВН или не менее унвылй ТФС.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, sergey_shandar, Вы писали:
_>>А что по поводу http://bitbucket.org ? Это позволит вам использовать все Mercurial, т.е. быть совместимыми с репозитариями на googlecode и на http://codeplex.com (где основная масса .NET проектов).
VD>codeplex.com == УГ. В нем опять же придется использовать СВН или не менее унвылй ТФС.
Здравствуйте, adontz, Вы писали:
VD>>codeplex.com == УГ. В нем опять же придется использовать СВН или не менее унвылй ТФС.
A>codeplex давным давно поддержимает Mercurial.
Вопрос в том, как он это делает? Гугль код его тоже поддерживает. Но очень плохо. Клоны которые в нем создаются явлются частными. Раздать права другим нельзя. Сделать код-ревью частного клона тоже нельзя. Средств попросить владельца основного репозитория залить изменения тоже нет. Надо писать письма.
Какие из проектов на codeplex.com используют Ртуть? Какие возможности ртути поддерживаются?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Вопрос в том, как он это делает? Гугль код его тоже поддерживает. Но очень плохо. Клоны которые в нем создаются явлются частными. Раздать права другим нельзя. Сделать код-ревью частного клона тоже нельзя. Средств попросить владельца основного репозитория залить изменения тоже нет. Надо писать письма.
Чем больше я юзаю гитхаб тем больше не хочу юзать что-то еще. Буквально сегодня один парень написал свой первый проект на немереле. Я глянул один файл и решил поправить. За пару минут, не вылезая из браузера, я поменял в методе стиль C# на стиль nemerle. У меня автоматом создался форк, а ему ушел пулреквест с коментарием, он его в браузере же принял. Я понимаю, что пример игрушечный, но всякие опечатки в коментариях или доках можно править и так. Очень эффективно. И сайт, в отличии от всего остального не тормозит.
Про всякие организации, удобство поиска и права в них я промолчу, пока не юзал.
Здравствуйте, Ziaw, Вы писали:
Z>Чем больше я юзаю гитхаб тем больше не хочу юзать что-то еще. Буквально сегодня один парень написал свой первый проект на немереле. Я глянул один файл и решил поправить. За пару минут, не вылезая из браузера, я поменял в методе стиль C# на стиль nemerle. У меня автоматом создался форк, а ему ушел пулреквест с коментарием, он его в браузере же принял. Я понимаю, что пример игрушечный, но всякие опечатки в коментариях или доках можно править и так. Очень эффективно. И сайт, в отличии от всего остального не тормозит.
Ну, давай переезжать. Кто-нибудь может этим заняться?
Нужно понять что у нас будет со внешними ссылками на СВН-репозитории вроде репозитория MPF.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Ziaw, Вы писали:
Z>Чем больше я юзаю гитхаб тем больше не хочу юзать что-то еще. Буквально сегодня один парень написал свой первый проект на немереле. Я глянул один файл и решил поправить. За пару минут, не вылезая из браузера, я поменял в методе стиль C# на стиль nemerle. У меня автоматом создался форк, а ему ушел пулреквест с коментарием, он его в браузере же принял. Я понимаю, что пример игрушечный, но всякие опечатки в коментариях или доках можно править и так. Очень эффективно. И сайт, в отличии от всего остального не тормозит.
Здравствуйте, Ziaw, Вы писали:
Z>Чем больше я юзаю гитхаб тем больше не хочу юзать что-то еще. Буквально сегодня один парень написал свой первый проект на немереле. Я глянул один файл и решил поправить. За пару минут, не вылезая из браузера, я поменял в методе стиль C# на стиль nemerle. У меня автоматом создался форк, а ему ушел пулреквест с коментарием, он его в браузере же принял. Я понимаю, что пример игрушечный, но всякие опечатки в коментариях или доках можно править и так. Очень эффективно. И сайт, в отличии от всего остального не тормозит.
А на Гитхабе можно добавлять коментарии к форкам? Предположим, вот нафигачил кто-то в своем форке изменений, сделал пул-реквест, но я поглядел код, а там ошибки или просто грязь какая-нить. Как мне сообщить владельцу форка, что в строке Х1 нужно вот это подправить, а в строке Х2 что-то еще?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>А на Гитхабе можно добавлять коментарии к форкам? Предположим, вот нафигачил кто-то в своем форке изменений, сделал пул-реквест, но я поглядел код, а там ошибки или просто грязь какая-нить. Как мне сообщить владельцу форка, что в строке Х1 нужно вот это подправить, а в строке Х2 что-то еще?
Пул реквест автоматически создаёт issue, в котором можно вести обсуждение.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
VD>>А на Гитхабе можно добавлять коментарии к форкам? Предположим, вот нафигачил кто-то в своем форке изменений, сделал пул-реквест, но я поглядел код, а там ошибки или просто грязь какая-нить. Как мне сообщить владельцу форка, что в строке Х1 нужно вот это подправить, а в строке Х2 что-то еще?
IT>Пул реквест автоматически создаёт issue, в котором можно вести обсуждение.
Это не то. Логично было бы давать возможность комментировать код по месту.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, adontz, Вы писали:
IT>>Что же тебе гит так не нравится? A>В сущности делоа даже не в VCS, а в хостинге как таковом. codeplex ассоциируется с .Net/Win32 ПО, в вот sourceforge, github или googlecode.com — нет.
Тебе шашечки или ехать?
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, VladD2, Вы писали:
IT>>Пул реквест автоматически создаёт issue, в котором можно вести обсуждение. VD>Это не то. Логично было бы давать возможность комментировать код по месту.
Можно прямо из GitExtensions комментировать реквест.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, IT, Вы писали:
IT>>Можно прямо из GitExtensions комментировать реквест.
VD>Еще раз. Как прокомментировать конкретный участок кода? Ну, вот кто-то накосячил...
К сожалению, в браузере кода я не нашел такой возможности. Комментировать можно только комиты и пулреквесты.
Есть некий воркэраунд, в браузере кода можно сделать патч/пулреквест с комментарием, нажатием двух кнопок редактировать-отправить.
В гита поддержка вложенных репозиториев значительно хуже чем в ртути.
У нас, насколько мне известно, для интеграции со студией используется ProjectBase с SVN-ки и ртуть отлично поддерживает вложенные репозитории с SVN.
В гите вложенные репозитории именуются модулями и поддерживаются только ГИТ-овские, а например, для SVN надо немного извратиться
Здравствуйте, VladD2, Вы писали:
IT>>Можно прямо из GitExtensions комментировать реквест. VD>А я могу форкнуть форк и уже там добавить по месту комментарии?
Форкнуть форк можно.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, BogdanMart, Вы писали:
BM>В гите вложенные репозитории именуются модулями и поддерживаются только ГИТ-овские, а например, для SVN надо немного извратиться
Честно говоря подход гит мне нравится больше. Сконвертили репозитарий, при желании обновляем. Или не обновляем, в общем сами решаем, любая версия nemerle содержит ссылку на ту версию с которой она и компилировалась.
Единственная серьезная проблема с гитом это нумерация версий. Если кто-то знает элегантное решение поделитесь.
Кратко, гит умеет выдавать номер ревизии считая от последнего тэга в текущей ветке. Так что существующую систему придется слегка изменить, но в разумную сторону. От каждого тэга пойдут свои ревизии. Плохо только то, что в разных бранчах можно получить одну и ту же ревизию, если не помечать их тэгами. Впрочем информацию о бранче можно куда-то еще поместить.
Вобщем у меня сейчас гит выдает версию v1.0-21-g4901905, которую несложно распарсить на момент компиляции.
Здравствуйте, VladD2, Вы писали:
IT>>Можно прямо из GitExtensions комментировать реквест. VD>Еще раз. Как прокомментировать конкретный участок кода? Ну, вот кто-то накосячил...
Оказывается можно комментировать код в коммитах.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, VladD2, Вы писали:
IT>>Можно прямо из GitExtensions комментировать реквест. VD>Еще раз. Как прокомментировать конкретный участок кода? Ну, вот кто-то накосячил...
Здравствуйте, IT, Вы писали:
VD>>Еще раз. Как прокомментировать конкретный участок кода? Ну, вот кто-то накосячил...
IT>Оказывается можно комментировать код в коммитах.
То есть, создать форк форка, прокомментировать его и сделать пул-реквест на исходный форк? Так?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>>>Еще раз. Как прокомментировать конкретный участок кода? Ну, вот кто-то накосячил... IT>>Оказывается можно комментировать код в коммитах. VD>То есть, создать форк форка, прокомментировать его и сделать пул-реквест на исходный форк? Так?
Получаешь пул-реквест. Это чей-то форк. Комментируешь изменения в коммитах этого реквеста. Форк форка делать не надо. Когда открывается пул-реквест, то автоматически создаётся issue. Все комментарии кода так же попадают в него, можно по ссылкам переходить к коду, как, например, здесь — https://github.com/igor-tkachev/bltoolkit/pull/17. На мой взгляд всё сделано довольно удобно и функционально.
Если нам не помогут, то мы тоже никого не пощадим.
Гит не имеет нативной поддержки windows.
Гит более сложен.
Выбирать систему контроля версий по наличию сторонних сервисов, думаю, не стоит.
У гитхаба более тяжелый и тормозной интерфей, чем у гугл-кода.
Здравствуйте, Suigintou, Вы писали:
S>Гит не имеет нативной поддержки windows.
Что такое нативная поддержка?
S>Гит более сложен.
Но и более удобен.
S>Выбирать систему контроля версий по наличию сторонних сервисов, думаю, не стоит.
А по каким критериям? Именно с этими сервисами в первую очередь должна быть работа, комит/пул/пуш практически одинаковы.
S>У гитхаба более тяжелый и тормозной интерфей, чем у гугл-кода.
У гуглкода нет большей части фич DVCS, там по сути только браузер кода и дерева комитов. Чтобы предложить патч надо писать письма.
Здравствуйте, Ziaw, Вы писали:
S>>Гит не имеет нативной поддержки windows. Z>Что такое нативная поддержка?
Git, насколько я знаю, работает через Cygwin. А хотелось бы чистого порта на win.
S>>Гит более сложен. Z>Но и более удобен.
А чем он удобней hg?
S>>Выбирать систему контроля версий по наличию сторонних сервисов, думаю, не стоит. Z>А по каким критериям? Именно с этими сервисами в первую очередь должна быть работа, комит/пул/пуш практически одинаковы.
По качеству проектирования и реализации самой системы, например.
S>>У гитхаба более тяжелый и тормозной интерфей, чем у гугл-кода. Z>У гуглкода нет большей части фич DVCS, там по сути только браузер кода и дерева комитов. Чтобы предложить патч надо писать письма.
А так ли много людей предлагают патчи, чтобы из-за этого менять хостинг?
Здравствуйте, Suigintou, Вы писали:
S>>>Гит не имеет нативной поддержки windows. Z>>Что такое нативная поддержка? S>Git, насколько я знаю, работает через Cygwin. А хотелось бы чистого порта на win.
есть msysgit.
S>>>Гит более сложен. Z>>Но и более удобен. S>А чем он удобней hg?
Бранчи, черипикинг.
S>>>Выбирать систему контроля версий по наличию сторонних сервисов, думаю, не стоит. Z>>А по каким критериям? Именно с этими сервисами в первую очередь должна быть работа, комит/пул/пуш практически одинаковы. S>По качеству проектирования и реализации самой системы, например.
Примерно одинаковы
S>>>У гитхаба более тяжелый и тормозной интерфей, чем у гугл-кода. Z>>У гуглкода нет большей части фич DVCS, там по сути только браузер кода и дерева комитов. Чтобы предложить патч надо писать письма. S>А так ли много людей предлагают патчи, чтобы из-за этого менять хостинг?
Предлагают, в svn вообще неудобно патчи как делать так и применять. Это останавливает людей. В том же тулките после переезда количество патчей увеличилось. Я недавно делал небольшой патч в немерл, svn напрягал, хоть у меня и доступ на запись есть. Без него точно бы ничего делать не стал.
Здравствуйте, Мишень-сан, Вы писали:
МС>Не холивара ради. А чем они в git лучше hg? Вроде ж и там есть лёгкие бранчи, и черипик (transplant).
Бранчи в hg мне разонравились после гита. Их можно создать только при комите и закрыть только при комите. В гите можно повесить бранч постфактум и удалить его тоже можно постфактум. \
К примеру: начал я что-то фиксить, сделал пару комитов и понял, что на все изменение нужен бранч.
Или: закончил я фикс, свел бранч с основной веткой, а закрыть его забыл.
Черипикинг я не сравнивал, рад, что в hg он тоже есть.
Здравствуйте, Мишень-сан, Вы писали:
МС>А чем они в git лучше hg?
Дополню немного: это просто разная идеология. В hg бранчем считается вся ветка в дереве комитов, а в git это просто скользящая по ревизиям в ветке метка. Эту метку всегда можно куда угодно поставить и всегда можно грохнуть (правда ветка не имеющая на конце имени тоже исчезнет).
Здравствуйте, Ziaw, Вы писали:
Z>Здравствуйте, Мишень-сан, Вы писали:
МС>>Не холивара ради. А чем они в git лучше hg? Вроде ж и там есть лёгкие бранчи, и черипик (transplant).
Z>Бранчи в hg мне разонравились после гита. Их можно создать только при комите и закрыть только при комите. В гите можно повесить бранч постфактум и удалить его тоже можно постфактум. \
Z>К примеру: начал я что-то фиксить, сделал пару комитов и понял, что на все изменение нужен бранч. Z>Или: закончил я фикс, свел бранч с основной веткой, а закрыть его забыл.
В Mercurial это делается через bookmarks.
Точно так же вешаешь/удаляешь постфактум.
Здравствуйте, zz-sergant, Вы писали:
Z>>К примеру: начал я что-то фиксить, сделал пару комитов и понял, что на все изменение нужен бранч. Z>>Или: закончил я фикс, свел бранч с основной веткой, а закрыть его забыл.
ZS>В Mercurial это делается через bookmarks. ZS>Точно так же вешаешь/удаляешь постфактум.
Что то я не понимаю, как вместо бранча использовать букмарк. Разве букмарки скользят по ревизиям после комита в них?
Здравствуйте, Ziaw, Вы писали:
Z>Что то я не понимаю, как вместо бранча использовать букмарк. Разве букмарки скользят по ревизиям после комита в них?
Да, скользят. Вообще, букмарки наиболее близкий аналог бранчей в гите, если не сказать, что это они и есть. Кстати, для ознакомления Mercurial: руководство по созданию веток
Здравствуйте, rameel, Вы писали:
R>Да, скользят. Вообще, букмарки наиболее близкий аналог бранчей в гите, если не сказать, что это они и есть. Кстати, для ознакомления Mercurial: руководство по созданию веток
Потестил, да похоже на гитовские бранчи. Вобщем остается только главное преимущество, github. К сожалению до его возможностей не дотягивает ни битбукет, ни codeplex, а уж тем более гуглкод. Его поддержка dvcs просто никакая.
Здравствуйте, Ziaw, Вы писали:
Z>Потестил, да похоже на гитовские бранчи. Вобщем остается только главное преимущество, github. К сожалению до его возможностей не дотягивает ни битбукет, ни codeplex, а уж тем более гуглкод. Его поддержка dvcs просто никакая.
Здравствуйте, VladD2, Вы писали:
VD>Ну, раз так, то я пожалуй согласен на первод N на гитхаб.
Только не называй репозиторий nemerle2, а то заводить новый репозиторий на каждую мажорную версию как-то не очень.
Здравствуйте, Suigintou, Вы писали:
S>Здравствуйте, VladD2, Вы писали:
VD>>Ну, раз так, то я пожалуй согласен на первод N на гитхаб. S>Только не называй репозиторий nemerle2, а то заводить новый репозиторий на каждую мажорную версию как-то не очень.
На эту можно. У нее нет стартовой точки в n1 с которой можно сделать бранч, это раз. Таскать с собой дальше груз двухстометрового репозитария (а n1 в гите весит именно столько) тоже не хочется.
Здравствуйте, Ziaw, Вы писали:
Z>Потестил, да похоже на гитовские бранчи. Вобщем остается только главное преимущество, github. К сожалению до его возможностей не дотягивает ни битбукет, ни codeplex, а уж тем более гуглкод. Его поддержка dvcs просто никакая.
Пожалуй, что соглашусь с этим. Послендяя новость о возможности коментировать чужие форки убедила меня окончательно. Гуглкоду и кодплексу поучиться бы у гитхаба.
Еще одним преимуществом можно назвать более зрелый клиент для винды.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
D>А можно для серых перевод сего зело гарного названия?
Перенос изменений сделанных в определённом коммите в рабочую версию. Полезно, если изменение сделанное, например, в master ветке хочется перенести в другую ветку.
Если нам не помогут, то мы тоже никого не пощадим.
Да вы месье теоретик.
Но ты прав — с технической т.з. это наиболее гибкое решение. Однако же наиболее затратное по времени, поддержке и отсутствию какого-либо пассивного продвижения, которое имеет место в случае CVS-хостинга.
Он платный и недешевый. Хотя раньше вроде видел его.
Если нам не помогут, то мы тоже никого не пощадим.
