В общим и целом, начитавшись про то какие хорошие распределенные системы контроля версий и поигравшись тестовыми проектами, я решил перевести рабочий проект со старого проверенного svn на что нить новомодное.
Выбирал между git и hg, выбрал последнего(и ногу прострелить себе сложней, и пишут что под винду интегрируется на ура). В качестве клиента — традиционно черепаха.
Конфигурационные требования у меня самые простые:
поставить-настроить под винду
желательно IIS в качестве веб сервиса
аутентификация-авторизация через Active Directory(изначально я вычитал что авторизация с расстановкой прав доступа — не получится)
ssl
интеграция в jira
Пишут что все хорошо можно настроить и все будет работать. Дал задачу админу. Прошло пару недель, админ ничего внятного не ответил — "разбираюсь"
Ну думаю, ет не совсем его профиль, подергаю я это хозяйство на новогодних праздниках.
обложился гуглем, бубном и кофе, начал священнодействовать. Можы у меня руки кривые и часть проблем можно решить, ткните меня фейсом лица плз — буду премного благодарен.
С самого начала смутил тот факт что официальная дока немногословна(про иис вообще ничего)
Весьма сильно меня смутил факт наличия собственного встроенного(sic!) веб-сервиса, конфигурируемого "в лоб" — zero security. Ну думаю, ладно фиг с вами нехай себе будет, в интранете дырки вроди уже позатыкивали, а между собой девы все равно сорцы шарят всеми возможными способами. Но для центрального репозитария это решение не подходило — никакой интеграции с AD да и вообще ни с чем.
Ну думаю scm-manager(тулзень такая есть) мне поможет. Увы не помог — опять таки, он сам по себе, никуда не интегрируется.
По итогу остались апач и иис. С апачем я знаком не шибко, выбрал IIS.
Как показало гугление, разные версии hg ведут себя несколько по разному, но думаю фиг с ним прорвемся.
Пару часов пошло на установление кошерного питона(ога, версии несовместимы, а дистрибутив рекомендуемой доступен тока в виде сорцов. Ну да ладно, прорвались.
Ышо пару часов приседаний и включился ssl. Ах ну да, самоподписанные сертификаты по дефолту не принимаются ни в каком виде — надо конфиги на всех девелоперских компах дописывать вручную. Супер.
Потом оказалось что во всех доках рекомендуют ставить x86 сборки hg(но после еще пары приседаний, поставились и x64). Необходимость пошагово ставить 3-4 дистрибутива(необходимость в некоторых проявляется просле гугления сообщений об ошибках), затем чего-то куда-то распаковывать и докопировать вручную... ну скажым прямо, не радует.
AD-аутентификация прикрутилась на удивление легко и непринужденно(новерное потому что ет полностью на совести IIS-a). А вот авторизация... ну официальное решение: назначить права чтения-записи на папку репозитария только нужным AD-пользователям. Класс. Все остальные пройдут аутентификацию и получат замечательное сообщение об ошибке 404 Not found — просто очень информативно. Я спустился в киоск купить пива, чтобы вернуться в рабочее состояние.
Решение положить файл mercurial.ini в каталог текущего пользователя тоже порадовало своей легкостью и непринужденностью(ет они сделали чтобы с UAC-ом не конфликтовать, супер!).
Затем был импорт исходников из svn. В общим давным давно чья то светлая голова в нашем тиме положила 3d-party дистрибутивы в svn(2 файла по 300 метров). Вот тут уж я наприседался. Полчал несколько раз out of memory(и на 86 и 64 разрядных сборках, с екстеншном largefiles и без него....) но в конце концов заимпортил через x64 черепаший hg(наверное там сборка более кошерная). Сначала без екстешна largefiles. Все хорошо, но при клонировании репозитария получал исключения что с потоком что-то не так. И все. Со включенным расширением largefiles переимпортил, но пришлось включать аналогичное расширение с аналогичными параметрами на всех девовских компах. Заняло это все не один час времени, но то уже такое, понять можно. В общим неужто нельзя эвристически отделить текстовый файл от бинарного и соотвсетвенно все бинарные по дефолту считать large????? Ужас и мрак!
После этого казалось бы уже можно было выдохнуть. Интеграция с JIRA удалась. "Родной" плугин не заработал, я так и не понял почему, а вот через FishEye все поднялось.
Пару приятных слов про черепаходевов. Во первых опять таки самоподписанные сертификаты: в диалоге pull есть галочка "принимать все сертификаты", в диалоге push — нету. Неужто трудно было скопировать поведение svn-черепахи(вопрос принимать всегда-принять только сейчас-не принимать)? Во вторых наверное кеширование логина-пароля к серверам, к которым обращаемся с pull-push это наверное осень сложная задача? Если кеширование пароля можно оправдать недостаточной секурностью(хотя в 90% случаев достаточно просто закодировать его), то почему нельзя логин то сохранить??? Ет жыж очевидно прям сразу, набивание логина-пароля задалбывает после 3го раза! В третьих дока в кошмарном состоянии: ее никто не обновляет, многие текстови и скриншоты относятся к версия, канувшим в лету год назад.
Ну и на закуску то что меня просто убило. Достаточно в mercurial.config на своей машине написать
[ui]
username = serega.brin
затем поломать весь код, залить его на центральный репозитарий, аутентифицировавшись как vasya.pupkin и.... вуаля!
Автор изменений, поломавших все — Серега Брин а не Вася Пупкин! Замечательно! Секурно и безопасно! Все по ssl и никаких самоподписанных сертификатов!
В общим резюме: для коммерческой корпоративной разработки hg сырой ни разу не годен, т.к. не выдерживает ни малейших требований по безопасности в первую очередь, по интеграции, легкости настройки, умению работать с бинарниками, — во вторую. Зато валом свистелок-перделок по типу собственного веб-сервиса, и всяких синтаксических сахаров по типу команды forget.
Вот подумываю свалить обратно на SVN(в первую очередь из-за полного произвола в авторстве ченджсетов). Неделя приседаний коту под хвост. У git-а говорят все еще печальней с точки зрения настройки-интеграции. Про bazaar даже не вспоминаю.
В общим вот, полегчало
Если у меня кривые руки — буду рад конструктивной критике.
i> По итогу остались апач и иис. С апачем я знаком не шибко, выбрал IIS.
В git всё работает через обычный shared repository, UNC-путь в сетевой папочке винды, а там права раздавай как обычно.
i> Затем был импорт исходников из svn. В общим давным давно чья то светлая голова в нашем тиме положила 3d-party дистрибутивы в svn(2 файла по 300 метров). Вот тут уж я
Хз, не пробовал, но, в крайнем случае, можно предварительно выпилить из svn его утилитами.
i> После этого казалось бы уже можно было выдохнуть. Интеграция с JIRA удалась. "Родной" плугин не заработал, я так и не понял почему, а вот через FishEye все поднялось.
Интегрировали как-то с git, вроде всё прошло гладко.
i> Ну и на закуску то что меня просто убило. Достаточно в mercurial.config на своей i> затем поломать весь код, залить его на центральный репозитарий, аутентифицировавшись как vasya.pupkin и.... вуаля!
Это прелесть распределённых систем, все репозитории равны. Поэтому нужно подписывать содержимое, в git применяют pgp. http://openpgpblog.tumblr.com/post/288011255/using-gpg-to-sign-git-tags
Правда искаропки он умеет только теги подписывать, но через хуки можно прикрутить подпись к каждому коммиту. Правда не уверен, что такое реально надо.
Здравствуйте, itslave, Вы писали:
I>По итогу остались апач и иис. С апачем я знаком не шибко, выбрал IIS.
Большая часть ваших проблем от того что вы решили всё прикрутить к IIS.
I>Ах ну да, самоподписанные сертификаты по дефолту не принимаются ни в каком виде
И это правильно, так и должно быть. Сертификат 50 баксов, имейте совесть
I>AD-аутентификация прикрутилась на удивление легко и непринужденно(новерное потому что ет полностью на совести IIS-a). А вот авторизация... ну официальное решение: назначить права чтения-записи на папку репозитария только нужным AD-пользователям.
Вот с апачем эта проблема решалась бы на раз-два. Но вы выбрали неподходящий для вашей задачи IIS.
I>Решение положить файл mercurial.ini в каталог текущего пользователя тоже порадовало своей легкостью и непринужденностью(ет они сделали чтобы с UAC-ом не конфликтовать, супер!).
Это они сделали, потому что mercurial.ini, вообще-то, содержит настройки пользователя, а не компьютера.
I>В общим давным давно чья то светлая голова в нашем тиме положила 3d-party дистрибутивы в svn(2 файла по 300 метров).
Ну вы ведь понимаете, что это плохо и репозитории вообще говоря не предназначены для хранения бинарных файлов, тем более таких больших.
I>Ну и на закуску то что меня просто убило. Достаточно в mercurial.config на своей машине написать I>
I>[ui]
I>username = serega.brin
I>затем поломать весь код, залить его на центральный репозитарий, аутентифицировавшись как vasya.pupkin и.... вуаля!
Здравствуйте, ., Вы писали:
.>Здравствуйте, itslave, Вы писали:
i>> По итогу остались апач и иис. С апачем я знаком не шибко, выбрал IIS. .>В git всё работает через обычный shared repository, UNC-путь в сетевой папочке винды, а там права раздавай как обычно.
Ну тоже не фонтан: доступ через http-https все ж таки намного удобней во всех смыслах.
i>> Затем был импорт исходников из svn. В общим давным давно чья то светлая голова в нашем тиме положила 3d-party дистрибутивы в svn(2 файла по 300 метров). Вот тут уж я .>Хз, не пробовал, но, в крайнем случае, можно предварительно выпилить из svn его утилитами.
Да, ет и наш косяк тоже. Но все ж таки падать на обработке 300 метрового файла с таким ярким сообщением об ошибке — ет все ж таки наверное считаю очень плохо.
i>> Ну и на закуску то что меня просто убило. Достаточно в mercurial.config на своей i> затем поломать весь код, залить его на центральный репозитарий, аутентифицировавшись как vasya.pupkin и.... вуаля! .>Это прелесть распределённых систем, все репозитории равны. Поэтому нужно подписывать содержимое, в git применяют pgp.
Ну все ж таки я хочу совсем немногого: чтобы изменения, которые записываются в репозитарий, приписывались тому пользователю, который авторизировался для этой операции. Считаю ет базовый функционал, который должен быть доступен из коробки. В любом случае пасип, почитаю. Может удастся прикрутить.
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, itslave, Вы писали:
I>>По итогу остались апач и иис. С апачем я знаком не шибко, выбрал IIS.
A>Большая часть ваших проблем от того что вы решили всё прикрутить к IIS.
... а вторая половина проблем я так понимаю — таки реально проблемы.
I>>Ах ну да, самоподписанные сертификаты по дефолту не принимаются ни в каком виде
A>И это правильно, так и должно быть. Сертификат 50 баксов, имейте совесть
Ну зачем мне это если я двумя тыками мыши сделаю такой же? Да еще и без головняка с выбором провайдера, отправкой ему реквизитов и т.д. и т.п. Ну неужто сложно в UI нарисовать 3 кнопки: принять одноразово, принимать всегда, отказать?
I>>AD-аутентификация прикрутилась на удивление легко и непринужденно(новерное потому что ет полностью на совести IIS-a). А вот авторизация... ну официальное решение: назначить права чтения-записи на папку репозитария только нужным AD-пользователям.
A>Вот с апачем эта проблема решалась бы на раз-два. Но вы выбрали неподходящий для вашей задачи IIS.
Возможно. Используя апач я смогу раздавать права на доступ к подпапкам разным AD группам без танцев и приседаний?
I>>Решение положить файл mercurial.ini в каталог текущего пользователя тоже порадовало своей легкостью и непринужденностью(ет они сделали чтобы с UAC-ом не конфликтовать, супер!).
A>Это они сделали, потому что mercurial.ini, вообще-то, содержит настройки пользователя, а не компьютера.
Не соглашусь. Там содержатся настройки репозитария. А они, имха, таки скорей компутерные чем пользовательские. Особенно с учетом того что некоторые репозитарии могут крутится исключительно как веб-сервисы и соотвественно совершенно непонятно откуда они будут читать свои настройки: из каталога пользователя под которым запущен сервис, из каталога пользователя, под которым сервис импенсорнифицируется(а этого каталога в приципе быть не должно), из какого нить третьего места(как и есть на самом деле).
I>>В общим давным давно чья то светлая голова в нашем тиме положила 3d-party дистрибутивы в svn(2 файла по 300 метров).
A>Ну вы ведь понимаете, что это плохо и репозитории вообще говоря не предназначены для хранения бинарных файлов, тем более таких больших.
Понимаю. Но считаю что при нынешнем то железе, ет не так и много, можно обработать. А если обработать не получается — то выдать вменяемое сообщение об ошибке сразу. А не out of memory через полчаса. I>>Ну и на закуску то что меня просто убило. Достаточно в mercurial.config на своей машине написать I>>
I>>[ui]
I>>username = serega.brin
I>>затем поломать весь код, залить его на центральный репозитарий, аутентифицировавшись как vasya.pupkin и.... вуаля!
A>И в логах веб-сервера останется vasya.pupkin.
ну все ж таки неблагодарное ет дело: шарится по логам веб-сервера несколькомесячной давности(если они сохранились), чтобы быть уверенным, кому пистона вставлять. Ща багу им запостю.
Здравствуйте, itslave, Вы писали:
i> Ну тоже не фонтан: доступ через http-https все ж таки намного удобней во всех смыслах.
В общем да, просто с https надо с сертами возиться... а http несекьюрно. Хотя с https работать удобнее...
i> Да, ет и наш косяк тоже. Но все ж таки падать на обработке 300 метрового файла с таким ярким сообщением об ошибке — ет все ж таки наверное считаю очень плохо.
Это да... но сообщение-то правильное, то что через пол часа... оно пыталось, ну не получилось...
Интересно попробовать гит, как он такое переварит.
i> Ну все ж таки я хочу совсем немногого: чтобы изменения, которые записываются в репозитарий, приписывались тому пользователю, который авторизировался для этой операции. Считаю ет базовый функционал, который должен быть доступен из коробки. В любом случае пасип, почитаю. Может удастся прикрутить.
Дело в том, что это требует специального репозитория, более равного. Например, это не будет работать в типичной для dvcs ситуации: один разработчик начинает делать какую-то фичу, всё ломает, ничего не компилится и не работает, толкать в публичный репозиторий смысла нет, поломается CI. И вдруг ему кидают более приоритетный таск. А другому разработчику надо доделать эту фичу. Он может напрямую вытянуть изменения прямо из чужого репозитория, доделать всё и потом уже затолкать в "центральный". Тогда он будет заталкивать и свои коммиты, и полученные окольным путём чужие.
Ещё чтобы можно было работать при проблемах с сервером и т.п.
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, itslave, Вы писали:
I>>По итогу остались апач и иис. С апачем я знаком не шибко, выбрал IIS.
A>Большая часть ваших проблем от того что вы решили всё прикрутить к IIS.
Странный подход... А если IIS — корпоративный стандарт и нельзя больше ничего, кроме него?
У IIS не такая маленькая доля на рынке, особенно в корпоративном сегменте, чтоб называющийся серьезным софт мог на него забивать
I>>Ну и на закуску то что меня просто убило. Достаточно в mercurial.config на своей машине написать I>>
I>>[ui]
I>>username = serega.brin
I>>затем поломать весь код, залить его на центральный репозитарий, аутентифицировавшись как vasya.pupkin и.... вуаля!
A>И в логах веб-сервера останется vasya.pupkin.
Так кем же будет подписано? Васей или Серегой? Кто автор в терминах Hg? Есть ли способ явно принять одну систему координат в рамках организации — и в ней вести авторизацию и главное — аутентификацию?
Здравствуйте, itslave, Вы писали:
A>>И это правильно, так и должно быть. Сертификат 50 баксов, имейте совесть I>Ну зачем мне это если я двумя тыками мыши сделаю такой же? Да еще и без головняка с выбором провайдера, отправкой ему реквизитов и т.д. и т.п. Ну неужто сложно в UI нарисовать 3 кнопки: принять одноразово, принимать всегда, отказать?
Нет, не сложно. В мире есть очень много простых и ненужных вещей В рамках предприятия могли бы развернуть центр сертицикации и распространять корневой сертификат групповыми политиками. Тогда опять же ничего не пришлось бы менять руками на машине разработчика. То есть правильный путь это не хер забить на центр выдачи сертициката, а поставить локально корневой сертификат в Trusted Roots.
A>>Вот с апачем эта проблема решалась бы на раз-два. Но вы выбрали неподходящий для вашей задачи IIS. I>Возможно. Используя апач я смогу раздавать права на доступ к подпапкам разным AD группам без танцев и приседаний?
Вы будете это задавать в конфиге апача с помошью регулрных выражений применяемых к URL. Кроме того конфиги апача поддерживают параметризированные макросы.
Далее мне надо только накидать пользователей в группы rosmurta-ro и rosmurta-rw
I>Не соглашусь. Там содержатся настройки репозитария.
Зря не соглашаетесь. Настройки репозитория содержатся в файле .hg\hgrc
A>>Ну вы ведь понимаете, что это плохо и репозитории вообще говоря не предназначены для хранения бинарных файлов, тем более таких больших. I>Понимаю. Но считаю что при нынешнем то железе, ет не так и много, можно обработать. А если обработать не получается — то выдать вменяемое сообщение об ошибке сразу. А не out of memory через полчаса.
A>>И в логах веб-сервера останется vasya.pupkin. I>ну все ж таки неблагодарное ет дело: шарится по логам веб-сервера несколькомесячной давности(если они сохранились), чтобы быть уверенным, кому пистона вставлять. Ща багу им запостю.
Здравствуйте, jazzer, Вы писали:
J>Странный подход... А если IIS — корпоративный стандарт и нельзя больше ничего, кроме него? J>У IIS не такая маленькая доля на рынке, особенно в корпоративном сегменте, чтоб называющийся серьезным софт мог на него забивать
Apache тоже вполне серьёзный софт и доля у него побольше будет. А одинаково хорошо поддерживать оба веб сервера на практике ни одна программа не умеет. Можно говорить про корпоративный стандарт, а можно просто хорошо сделать своё дело на том, на чём получается проще, быстрее, качественнее.
Здравствуйте, Aquary, Вы писали:
A>>И в логах веб-сервера останется vasya.pupkin. A>Так кем же будет подписано? Васей или Серегой? Кто автор в терминах Hg?
В терминах HG ui.username это просто ничего не значащее текстовое поле. Считайте что это DisplayName. Туда можно вписать любую последовательность символов, например, "Иван Иванов, Старший разработчик, Победитель пивного чемпионата".
A>Есть ли способ явно принять одну систему координат в рамках организации — и в ней вести авторизацию и главное — аутентификацию?
Как я уже написал, можно написать incoming hook проверяющий что значение поля ui.username и имя пользователя в текущем конткексте аутентификации совпадают. Есть несколько встроенных хуков работающих с ui.username, так чтоконкретный код можно там подсмотреть.
Здравствуйте, adontz, Вы писали:
A>>Есть ли способ явно принять одну систему координат в рамках организации — и в ней вести авторизацию и главное — аутентификацию?
A>Как я уже написал, можно написать incoming hook проверяющий что значение поля ui.username и имя пользователя в текущем конткексте аутентификации совпадают. Есть несколько встроенных хуков работающих с ui.username, так чтоконкретный код можно там подсмотреть.
Поставлю вопрос иначе — какие приседания нужно сделать в рамках команды разработчиков, когда нужно внедрить Hg с аутентификацией и авторизацией? Например, есть список людей, не связанных единым ActiveDirectory, есть лишь некие айди. Пусть это будет email. Что делается на стороне сервера (надстройки, хуки), что — на стороне каждого юзера (конфиги и т.п.)?
Здравствуйте, Aquary, Вы писали:
A>Поставлю вопрос иначе — какие приседания нужно сделать в рамках команды разработчиков, когда нужно внедрить Hg с аутентификацией и авторизацией?
Уметь настраивать linux/apache. Я пишу под Windows/.Net но HG крутится в виртуалке с Дебианом. Эта конфигурация оказалась проще в администрировании, чем Apache под Windows, например.
A>Например, есть список людей, не связанных единым ActiveDirectory, есть лишь некие айди. Пусть это будет email. Что делается на стороне сервера (надстройки, хуки), что — на стороне каждого юзера (конфиги и т.п.)?
На стороне юзера ничего не делается особого, на стороне сервера авторизация и аутентификация настраиваются в апаче.
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, jazzer, Вы писали:
J>>Странный подход... А если IIS — корпоративный стандарт и нельзя больше ничего, кроме него? J>>У IIS не такая маленькая доля на рынке, особенно в корпоративном сегменте, чтоб называющийся серьезным софт мог на него забивать
A>Apache тоже вполне серьёзный софт и доля у него побольше будет. А одинаково хорошо поддерживать оба веб сервера на практике ни одна программа не умеет. Можно говорить про корпоративный стандарт, а можно просто хорошо сделать своё дело на том, на чём получается проще, быстрее, качественнее.
Что значит "говорить про корпоративный стандарт"? Корпоративные стандарты обычно спущены сверху в форме запрета на все остальное, и изменить их — дело не одного месяца.
Здравствуйте, jazzer, Вы писали:
J>Что значит "говорить про корпоративный стандарт"? Корпоративные стандарты обычно спущены сверху в форме запрета на все остальное, и изменить их — дело не одного месяца.
А кто просить менять вообще всё? Почему в Apache нельзя хостить только HG? Почему если TFS/SVN заменли на HG, то договориться про IIS большая проблема?
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, jazzer, Вы писали:
J>>Что значит "говорить про корпоративный стандарт"? Корпоративные стандарты обычно спущены сверху в форме запрета на все остальное, и изменить их — дело не одного месяца.
A>А кто просить менять вообще всё? Почему в Apache нельзя хостить только HG? Почему если TFS/SVN заменли на HG, то договориться про IIS большая проблема?
Не "вообще всё", а добавить апач в список разрешенных к использованию веб-серверов. Это обычно означает необходимость наличия квалифицированных админов, которые смогут управлять апачем и знают его подводные грабли и дыры в безопасности и как их устранять, наличие ресурсов для создания firmwide package, в котором будет включено то, что можно, и исключено то, что нельзя (а модулей у апача море), кто-то далее должен отслеживать апдейты и пихать их в этот централизованный пакет и потом обновлять апач на всех машинах по всей компании, и прочая и прочая.
В маленьких конторах таких проблем, ессно, нет, а в больших — в полный рост. И если HG хочет рулить в этом сегменте, а не только в опенсорце, он должен поддерживать как можно больше.
Здравствуйте, jazzer, Вы писали:
J>Не "вообще всё", а добавить апач в список разрешенных к использованию веб-серверов. Это обычно означает необходимость наличия квалифицированных админов, которые смогут управлять апачем и знают его подводные грабли и дыры в безопасности и как их устранять, наличие ресурсов для создания firmwide package, в котором будет включено то, что можно, и исключено то, что нельзя (а модулей у апача море), кто-то далее должен отслеживать апдейты и пихать их в этот централизованный пакет и потом обновлять апач на всех машинах по всей компании, и прочая и прочая.
Ещё раз, почему добавить Mercurial, который надо устанавливать на каждый компьютер разработчика и который, соответственно, создаёт гораздо больше проблем админам — это не проблема, а добавить Apache — проблема?
Почему Mercurial и Apache надо запрашивать отдельно, а не как комплект?
J>В маленьких конторах таких проблем, ессно, нет, а в больших — в полный рост. И если HG хочет рулить в этом сегменте, а не только в опенсорце, он должен поддерживать как можно больше.
В больших конторах выбор софта делается не так как ты описал. Там либо купят TFS за откат, либо поставят Apache+Mercurial и назначат для них отдельного админа.
Здравствуйте, ., Вы писали:
i>> Ну все ж таки я хочу совсем немногого: чтобы изменения, которые записываются в репозитарий, приписывались тому пользователю, который авторизировался для этой операции. Считаю ет базовый функционал, который должен быть доступен из коробки. В любом случае пасип, почитаю. Может удастся прикрутить. .>Дело в том, что это требует специального репозитория, более равного. Например, это не будет работать в типичной для dvcs ситуации: один разработчик начинает делать какую-то фичу, всё ломает, ничего не компилится и не работает, толкать в публичный репозиторий смысла нет, поломается CI. И вдруг ему кидают более приоритетный таск. А другому разработчику надо доделать эту фичу. Он может напрямую вытянуть изменения прямо из чужого репозитория, доделать всё и потом уже затолкать в "центральный". Тогда он будет заталкивать и свои коммиты, и полученные окольным путём чужие. .>Ещё чтобы можно было работать при проблемах с сервером и т.п.
Ну все ж таки буду настаивать, что правильное поведение — ет считать автором того чувака, который авторизировался при пуше в репозитарий. У него кстате есть свой локальный репо, и при разборе полетов можно поднять историю по нему и посмотреть кто чего туда коммитил. И так далее по цепочке. По крайней мере ясно откуда ноги растут, кого пинать и в какой последовательности.
Как вариант — иметь 2 поля, "автор ченджсета"(тут кто угодно может быть) и "автор пуша"(тут строго тот кто авторизировался).
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, Aquary, Вы писали:
A>>Поставлю вопрос иначе — какие приседания нужно сделать в рамках команды разработчиков, когда нужно внедрить Hg с аутентификацией и авторизацией?
A>Уметь настраивать linux/apache. Я пишу под Windows/.Net но HG крутится в виртуалке с Дебианом. Эта конфигурация оказалась проще в администрировании, чем Apache под Windows, например.
Я думаю это таки ответ, после которого мы таки откатимся обратно на svn.
Поясняю: у нас небольшая фирма, около 10 девелоперов, еще человек 15 qa, сейзлов и т.д. Большой конторой нас назвать трудно, многоуровневыми иерархиями еще не обросли, но все таки считаю что уже в таких масштабах необходима формализация(в авторстве чейнджсетов так уж точно) и про безопасность тоже всерьез думаем. Наш админ специализируется на винде, потому как девелопим мы на .NET и у нас все на винде. Соответственно нам банально нереентабельно держать еще одного "линухового" админа исключительно для администрирования hg, а требовать от нашего изучить апач-линух в сжатые сроки наверное тоже неправильно. Для хостинга svn мы пользовали апач, в составе visualsvn server. Но там аффтар продукта потрудился чтобы настроить, обрезать все лишнее, заткнуть все дырки, сделать администрирование(в том числе настройки аутентификации-авторизации) максимально простыми и понятными.
Конечно посмотрю скок надо сделать приседаний чтобы хуки заставить заработать, можы получится.
Кстате багу я им таки открыл, они ее закрыли. Типа для опен сорца такой функционал необязателен. Один камент тоже советует воспользоваться хуками, или екстеншнами которые может быть есть в паблике или может быть умеют это делать — погуглю.
Но второй камент меня просто убил.
Mercurial assumes John owns his machine and thus there is nothing the
"central" repository can do to prevent him from making a "mary" account on
his machine, or modifying hg to pretend to be Mary.
Furthermore, some people (like myself) use this capability daily to do their
work.
Т.е. люди не понимают что ревью ченджсетов(регулярное или из-за факапа) — ет таки отвественная процедура, по результатам которой нахомутавший может огрести по самое не могу, вплоть до увольнений в особо запущенных случаях. И кодревьюеру надо просто и ясно видеть, кто запушил чейнджсет в репозитарий.
Но мое мнение о hg осталось неизменно: для корпоративной бизнес разработке в среде windows он не годится.
Здравствуйте, itslave, Вы писали:
I>Наш админ специализируется на винде, потому как девелопим мы на .NET и у нас все на винде. Соответственно нам банально нереентабельно держать еще одного "линухового" админа исключительно для администрирования hg, а требовать от нашего изучить апач-линух в сжатые сроки наверное тоже неправильно.
Я вообще программист, а не админ. Было любопытно и справился за три дня, при том что Линукс до того отродясь не трогал, даже как файл копировать не знал. Что это за админ такой что Линукс ставить не умеет? Тем более Debina/CentOS, где всё из пакетов? Эникейщик это, а не админ. Основные утилиты: putty и winscp, используются и при администрировании сетевого обрудования, например, Cisco. Не сгущайте краски, если не быть предвзятым и нацеленынм на провал, ничего сложного в необходимом вам уровне администрирования Apache и Linux нет. Единственная причина по которой инсталляция может растянуться больше, чем на неделю — бан в гугле.
I>Для хостинга svn мы пользовали апач, в составе visualsvn server. Но там аффтар продукта потрудился чтобы настроить, обрезать все лишнее, заткнуть все дырки, сделать администрирование(в том числе настройки аутентификации-авторизации) максимально простыми и понятными.
В итоге получился недоапач, которы нельзя апдейтить нормально, нельзя использовать для других целей. Я их поделку покрутил в своё время и снёс.
I>Конечно посмотрю скок надо сделать приседаний чтобы хуки заставить заработать, можы получится.
Их вроде на любом языке можно писать, но на Питоне удобнее.
I>Т.е. люди не понимают что ревью ченджсетов(регулярное или из-за факапа) — ет таки отвественная процедура, по результатам которой нахомутавший может огрести по самое не могу, вплоть до увольнений в особо запущенных случаях. И кодревьюеру надо просто и ясно видеть, кто запушил чейнджсет в репозитарий.
Нет. Это вы не понимаете, что используете модель постмодерирования, а в FOSS принята модель премодерирования. Почитайте про cherry-picking.
I>Но мое мнение о hg осталось неизменно: для корпоративной бизнес разработке в среде windows он не годится.
Здравствуйте, itslave, Вы писали:
I>Но второй камент меня просто убил.
Furthermore, some people (like myself) use this capability daily to do their work.
I>Т.е. люди не понимают что ревью ченджсетов(регулярное или из-за факапа) — ет таки отвественная процедура, по результатам которой нахомутавший может огрести по самое не могу, вплоть до увольнений в особо запущенных случаях. И кодревьюеру надо просто и ясно видеть, кто запушил чейнджсет в репозитарий.
Кстати, это как раз для ревью и используется. Вы присылаете свой changeset мне на проверку, я его одобряю и делаю push в центральный репозиторий. Аутентифицировался я, автор — вы.
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, jazzer, Вы писали:
J>>Не "вообще всё", а добавить апач в список разрешенных к использованию веб-серверов. Это обычно означает необходимость наличия квалифицированных админов, которые смогут управлять апачем и знают его подводные грабли и дыры в безопасности и как их устранять, наличие ресурсов для создания firmwide package, в котором будет включено то, что можно, и исключено то, что нельзя (а модулей у апача море), кто-то далее должен отслеживать апдейты и пихать их в этот централизованный пакет и потом обновлять апач на всех машинах по всей компании, и прочая и прочая.
A>Ещё раз, почему добавить Mercurial, который надо устанавливать на каждый компьютер разработчика и который, соответственно, создаёт гораздо больше проблем админам — это не проблема, а добавить Apache — проблема? A>Почему Mercurial и Apache надо запрашивать отдельно, а не как комплект?
Это, конечно, тоже вариант, но я бы лично его не разрешил, учитывая, что апач может шариться несколькими подобными инсталляциями (например, какая-нть вики тоже потребует своего апача — и чего?) и рассматривал бы отдельно апач и отдельно меркуриал. Не говоря уже о том, что апач на 80 порте должен работать из-под рута.
J>>В маленьких конторах таких проблем, ессно, нет, а в больших — в полный рост. И если HG хочет рулить в этом сегменте, а не только в опенсорце, он должен поддерживать как можно больше.
A>В больших конторах выбор софта делается не так как ты описал. Там либо купят TFS за откат, либо поставят Apache+Mercurial и назначат для них отдельного админа.
Ну конечно, "не верь глазам своим". Кто поставит? Кто назначит? Если в политике компании записано: "Веб-сервер — IIS", то кто-то должен будет взять на себя личную ответственность за нарушение полиси, либо взять на себя труд добиться официального ее изменения.
А если меркуриал говорит своим пользователям: "Мне пофиг на ваши внутрикорпоративные проблемы, бодайтесь сами", то...
Здравствуйте, adontz, Вы писали:
A>Я вообще программист, а не админ. Было любопытно и справился за три дня, при том что Линукс до того отродясь не трогал, даже как файл копировать не знал. Что это за админ такой что Линукс ставить не умеет? Тем более Debina/CentOS, где всё из пакетов? Эникейщик это, а не админ. Основные утилиты: putty и winscp, используются и при администрировании сетевого обрудования, например, Cisco. Не сгущайте краски, если не быть предвзятым и нацеленынм на провал, ничего сложного в необходимом вам уровне администрирования Apache и Linux нет. Единственная причина по которой инсталляция может растянуться больше, чем на неделю — бан в гугле.
Ну наверное под "администрировать" мы понимаем разные вещи. Да, поставить из коробки нетрудно. Но я считаю что этого явно недостаточно, надо уметь настраивать, интегрировать, затыкать имеющиеся и потенциальные дырки... в общим гуглить чуть ли не неделями.
A>В итоге получился недоапач, которы нельзя апдейтить нормально, нельзя использовать для других целей. Я их поделку покрутил в своё время и снёс.
Свою задачу он решает. А большего от него не требуется. Конечно с интеграцией оно не совсем хорошо(в смысле порт нужен отдельный), но ет плата за простоту и легкость в администрировании и настройке.
I>>Т.е. люди не понимают что ревью ченджсетов(регулярное или из-за факапа) — ет таки отвественная процедура, по результатам которой нахомутавший может огрести по самое не могу, вплоть до увольнений в особо запущенных случаях. И кодревьюеру надо просто и ясно видеть, кто запушил чейнджсет в репозитарий.
A>Нет. Это вы не понимаете, что используете модель постмодерирования, а в FOSS принята модель премодерирования. Почитайте про cherry-picking.
Премодерирование ет хорошо но увы не универсально. Ретроспективы, разбор факапов — етого всего премодерирование не решает(хотя конечно может уменьшить количество таких траблов).
Здравствуйте, jazzer, Вы писали:
J>Это, конечно, тоже вариант, но я бы лично его не разрешил, учитывая, что апач может шариться несколькими подобными инсталляциями (например, какая-нть вики тоже потребует своего апача — и чего?) и рассматривал бы отдельно апач и отдельно меркуриал. Не говоря уже о том, что апач на 80 порте должен работать из-под рута.
Из под рута только bind+listen+accept делается, реальная обработка запроса (recv/send) происходит в контексте www-data
A>>В больших конторах выбор софта делается не так как ты описал. Там либо купят TFS за откат, либо поставят Apache+Mercurial и назначат для них отдельного админа. J>Ну конечно, "не верь глазам своим". Кто поставит? Кто назначит? Если в политике компании записано: "Веб-сервер — IIS", то кто-то должен будет взять на себя личную ответственность за нарушение полиси, либо взять на себя труд добиться официального ее изменения.
Тот же кто SVN/TFS поменяет на HG. Я реально не поменяю почему замена VCS это меньшая проблема, чем добавление веб-сервера.
J>А если меркуриал говорит своим пользователям: "Мне пофиг на ваши внутрикорпоративные проблемы, бодайтесь сами", то...
Да нет, Mercurial тут вообще не при чём. Mercurial ничего не говорит.
Это IIS говорит — хрен вам, а не гибкая авторизация. И уже отсюда возникает вопрос об Apache. А Mercurial просто не дублирует то что Apache и так делает хорошо.
Здравствуйте, itslave, Вы писали:
I>Ну наверное под "администрировать" мы понимаем разные вещи. Да, поставить из коробки нетрудно. Но я считаю что этого явно недостаточно, надо уметь настраивать, интегрировать, затыкать имеющиеся и потенциальные дырки... в общим гуглить чуть ли не неделями.
Вы опять усложняете. Наверняка всё администрирование безопасности Windows свелось к включённому Automatic Updates и слегка настроенному файрволу. Почему нельзя тоже самое на том же уровне сделать в Linux?
I>>>Т.е. люди не понимают что ревью ченджсетов(регулярное или из-за факапа) — ет таки отвественная процедура, по результатам которой нахомутавший может огрести по самое не могу, вплоть до увольнений в особо запущенных случаях. И кодревьюеру надо просто и ясно видеть, кто запушил чейнджсет в репозитарий. A>>Нет. Это вы не понимаете, что используете модель постмодерирования, а в FOSS принята модель премодерирования. Почитайте про cherry-picking. I>Премодерирование ет хорошо но увы не универсально. Ретроспективы, разбор факапов — етого всего премодерирование не решает(хотя конечно может уменьшить количество таких траблов).
Делать ревью вам никто и не запрещает. У вас проблема вообще не в идентификации, вы обсуждаете потенциальный сабботаж. Ваш use case: кто-то сознательно сделал push некачественных исходников под чужим именем. Это что, правда так актуально? Серьёзно?
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, itslave, Вы писали:
I>>Но второй камент меня просто убил. A>
A>Furthermore, some people (like myself) use this capability daily to do their work.
I>>Т.е. люди не понимают что ревью ченджсетов(регулярное или из-за факапа) — ет таки отвественная процедура, по результатам которой нахомутавший может огрести по самое не могу, вплоть до увольнений в особо запущенных случаях. И кодревьюеру надо просто и ясно видеть, кто запушил чейнджсет в репозитарий.
A>Кстати, это как раз для ревью и используется. Вы присылаете свой changeset мне на проверку, я его одобряю и делаю push в центральный репозиторий. Аутентифицировался я, автор — вы.
Я в соседней ветке писал — для меня(подозреваю что далеко не только для меня) пожалуй оптимальным было бы 2 поля: автор(все что угодно, как и есть в меркурале) и "коммитер" — тот кто делает пуш в "центральный" репозитарий — тут исключительно логин под которыми чувак аутентифицируется. Но если выбирать какая инфа важней, то имха выбор очевиден.
Здравствуйте, adontz, Вы писали:
A>Вы опять усложняете. Наверняка всё администрирование безопасности Windows свелось к включённому Automatic Updates и слегка настроенному файрволу. Почему нельзя тоже самое на том же уровне сделать в Linux?
Отнюдь. Интранетовские настройки прав доступа опустим, но все что торчит наружу сурьезно порублено и накостомайзено.
A>Делать ревью вам никто и не запрещает. У вас проблема вообще не в идентификации, вы обсуждаете потенциальный сабботаж. Ваш use case: кто-то сознательно сделал push некачественных исходников под чужим именем. Это что, правда так актуально? Серьёзно?
Да. Это может потребоваться один раз в 20 лет, но тогда это действительно понадобится. На моей практике был капитальный один разбор по сорцам годичной давности, с твердым намерением "уволить виноватого". Но виноватый этого разбора не дождался и свалил за несколько месяцев до него.
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, jazzer, Вы писали:
J>>Это, конечно, тоже вариант, но я бы лично его не разрешил, учитывая, что апач может шариться несколькими подобными инсталляциями (например, какая-нть вики тоже потребует своего апача — и чего?) и рассматривал бы отдельно апач и отдельно меркуриал. Не говоря уже о том, что апач на 80 порте должен работать из-под рута.
A>Из под рута только bind+listen+accept делается, реальная обработка запроса (recv/send) происходит в контексте www-data
Тем не менее сервер надо стартовать под рутом, не? А одно это — уже большая головная боль для любого безопасника, а уж плагинная система апача — это вообще одна большая дыра.
A>>>В больших конторах выбор софта делается не так как ты описал. Там либо купят TFS за откат, либо поставят Apache+Mercurial и назначат для них отдельного админа. J>>Ну конечно, "не верь глазам своим". Кто поставит? Кто назначит? Если в политике компании записано: "Веб-сервер — IIS", то кто-то должен будет взять на себя личную ответственность за нарушение полиси, либо взять на себя труд добиться официального ее изменения.
A>Тот же кто SVN/TFS поменяет на HG. Я реально не поменяю почему замена VCS это меньшая проблема, чем добавление веб-сервера.
Очень просто. VCS обычно идет по графе Developer tools, вместе со всякими библиотеками и прочими решарперами, и рулится это обычно только отделом разработки с гораздо более мягкой политикой. А вот веб-сервер — это глобальная вещь, которая, в принципе, может смотреть наружу и дает доступ внутрь сети извне, и должна огораживаться с соответствующий строгостью.
Ты вон и сам там рядом говорил "кастрированный апач, нельзя еще что-нть запустить" — что, очевидно, противоречит изначальной заявке "апач как неотъемлемая часть хг": тебе разрешишь поставить апач для хг, а ты на нем полноценный сервак развернешь и будешь секретные сорцы из дома выкачивать.
J>>А если меркуриал говорит своим пользователям: "Мне пофиг на ваши внутрикорпоративные проблемы, бодайтесь сами", то...
A>Да нет, Mercurial тут вообще не при чём. Mercurial ничего не говорит. A>Это IIS говорит — хрен вам, а не гибкая авторизация. И уже отсюда возникает вопрос об Apache. А Mercurial просто не дублирует то что Apache и так делает хорошо.
Да я ж не спорю, что Апач лучше ИИСа. Я говорю только о том, что в корпоративном сегменте обычно не разрешают ставить что попало, и поэтому любой софт, который хочет в корпоративный сегмент пробиться, должен поддерживать то, что там чаще всего используется, и ИИС в этот список, разумеется, входит. А без этого это будет инструментов опенсорсников, о чем, в принципе, и говорят приведенные комменты его разработчиков.
You will always get what you always got
If you always do what you always did
Re[9]: О Mercurial (грустно)
От:
Аноним
Дата:
10.01.12 08:46
Оценка:
I>Ну наверное под "администрировать" мы понимаем разные вещи. Да, поставить из коробки нетрудно. Но я считаю что этого явно недостаточно, надо уметь настраивать, интегрировать, затыкать имеющиеся и потенциальные дырки... в общим гуглить чуть ли не неделями.
И как ваш "админ" закрывает прорехи апача(дыр и там находят) в связке с svn? Если там нормально обновить то его в используемом вами комплекте нельзя ???? Гуглит неделями и накатывает новую версию всего комплекта?
Здравствуйте, itslave, Вы писали:
I>обложился гуглем, бубном и кофе, начал священнодействовать. Можы у меня руки кривые и часть проблем можно решить, ткните меня фейсом лица плз — буду премного благодарен.
отличный слог, порадовали
I>>Ну наверное под "администрировать" мы понимаем разные вещи. Да, поставить из коробки нетрудно. Но я считаю что этого явно недостаточно, надо уметь настраивать, интегрировать, затыкать имеющиеся и потенциальные дырки... в общим гуглить чуть ли не неделями.
А>И как ваш "админ" закрывает прорехи апача(дыр и там находят) в связке с svn? Если там нормально обновить то его в используемом вами комплекте нельзя ???? Гуглит неделями и накатывает новую версию всего комплекта?
На работе в свое время перешли на git и еще ни разу не пожалели. Правда часть сидит на linux, часть на mac.
Интеграция с JIRA отличная, все работает на ура, с бинариками вроде проблем не было особых.
Здравствуйте, A13x, Вы писали:
A>Здравствуйте, itslave, Вы писали:
I>>...
A>На работе в свое время перешли на git и еще ни разу не пожалели. Правда часть сидит на linux, часть на mac. A>Интеграция с JIRA отличная, все работает на ура, с бинариками вроде проблем не было особых.
A>Что там не так с гитом?
Если пользователь делает push в репозитарий, который требует аутентификации, можно ли быть уверенным что в качестве автора изменений будет логин, под которым пользователь аутентифицировался?
Здравствуйте, itslave, Вы писали:
I>Здравствуйте, adontz, Вы писали: A>>Вы опять усложняете. Наверняка всё администрирование безопасности Windows свелось к включённому Automatic Updates и слегка настроенному файрволу. Почему нельзя тоже самое на том же уровне сделать в Linux? I>Отнюдь. Интранетовские настройки прав доступа опустим, но все что торчит наружу сурьезно порублено и накостомайзено.
HG нужен только HTTP/HTTPS, особо настраивать тут нечего.
A>>Делать ревью вам никто и не запрещает. У вас проблема вообще не в идентификации, вы обсуждаете потенциальный сабботаж. Ваш use case: кто-то сознательно сделал push некачественных исходников под чужим именем. Это что, правда так актуально? Серьёзно? I>Да. Это может потребоваться один раз в 20 лет, но тогда это действительно понадобится. На моей практике был капитальный один разбор по сорцам годичной давности, с твердым намерением "уволить виноватого". Но виноватый этого разбора не дождался и свалил за несколько месяцев до него.
Вам уже везде сказали, то что вы хотите делается простейшим хуком. Даже какой-то стандартный посоветовали.
Здравствуйте, jazzer, Вы писали:
A>>Из под рута только bind+listen+accept делается, реальная обработка запроса (recv/send) происходит в контексте www-data J>Тем не менее сервер надо стартовать под рутом, не? А одно это — уже большая головная боль для любого безопасника, а уж плагинная система апача — это вообще одна большая дыра.
Да, первый процесс любого сервера слушающего порт ниже 1024 стартуется в Линуксе под рутом.
A>>Тот же кто SVN/TFS поменяет на HG. Я реально не поменяю почему замена VCS это меньшая проблема, чем добавление веб-сервера. J>Очень просто. VCS обычно идет по графе Developer tools, вместе со всякими библиотеками и прочими решарперами, и рулится это обычно только отделом разработки с гораздо более мягкой политикой. А вот веб-сервер — это глобальная вещь, которая, в принципе, может смотреть наружу и дает доступ внутрь сети извне, и должна огораживаться с соответствующий строгостью.
Странные вещи говоришь. Вот sharepoint интегрированный с TFS (отдельный инстанс) это Developer Tools или нет? redmine, trac или bugzilla работающие под тем же Apache или как самостоятельные веб серверы это что? Почему если программа случает на 80м порту то она сразу выпадает из списка Developer Tools?
J>Ты вон и сам там рядом говорил "кастрированный апач, нельзя еще что-нть запустить" — что, очевидно, противоречит изначальной заявке "апач как неотъемлемая часть хг": тебе разрешишь поставить апач для хг, а ты на нем полноценный сервак развернешь и будешь секретные сорцы из дома выкачивать.
Я как кто? Я как админ и так всё домой унесу, я как программист Apache настраивать не смогу.
J>Да я ж не спорю, что Апач лучше ИИСа. Я говорю только о том, что в корпоративном сегменте обычно не разрешают ставить что попало, и поэтому любой софт, который хочет в корпоративный сегмент пробиться, должен поддерживать то, что там чаще всего используется, и ИИС в этот список, разумеется, входит. А без этого это будет инструментов опенсорсников, о чем, в принципе, и говорят приведенные комменты его разработчиков.
Я ещё раз повторяю, не может быть такого чтобы человек пробил установку софта на каждую рабочую станцию (hg, TortoiseHG, VisualHG/HgScc) и не пробил установку Apache на один сервер, которым пользутся только разработчики. Проблема надумана. Правда. Честное программистское.
Здравствуйте, adontz, Вы писали: A>>>Делать ревью вам никто и не запрещает. У вас проблема вообще не в идентификации, вы обсуждаете потенциальный сабботаж. Ваш use case: кто-то сознательно сделал push некачественных исходников под чужим именем. Это что, правда так актуально? Серьёзно? I>>Да. Это может потребоваться один раз в 20 лет, но тогда это действительно понадобится. На моей практике был капитальный один разбор по сорцам годичной давности, с твердым намерением "уволить виноватого". Но виноватый этого разбора не дождался и свалил за несколько месяцев до него.
A>Вам уже везде сказали, то что вы хотите делается простейшим хуком. Даже какой-то стандартный посоветовали.
Стандартный увы то что надо не делает. Похожих примеров(конкретно вытаскивание аутентификационной инфы) я не нашел, может плохо искал.
Здравствуйте, itslave, Вы писали:
I>Стандартный увы то что надо не делает. Похожих примеров(конкретно вытаскивание аутентификационной инфы) я не нашел, может плохо искал.
Я ошибся, хук нужен не incoming, а pretxnchangegroup
[hooks]
pretxnchangegroup = /path/to/script
вот такой вот баш скрипт хука
echo ${HG_URL:14} #отрезал первые 14 символов
hg log -r $HG_NODE --template "{author}" $PWD
выдаёт мне имя аутентифицированного пользователя и имя из лога. Дальше их надо сравнить и вернуть не 0 если надо прервать операцию. пример развивать не стал, так как вы CMD или Powershell будете использовать.
Здравствуйте, itslave, Вы писали:
.>>Дело в том, что это требует специального репозитория, более равного. Например, это не будет работать в типичной для dvcs ситуации: один разработчик начинает делать какую-то фичу, всё ломает, ничего не компилится и не работает, толкать в публичный репозиторий смысла нет, поломается CI. И вдруг ему кидают более приоритетный таск. А другому разработчику надо доделать эту фичу. Он может напрямую вытянуть изменения прямо из чужого репозитория, доделать всё и потом уже затолкать в "центральный". Тогда он будет заталкивать и свои коммиты, и полученные окольным путём чужие. .>>Ещё чтобы можно было работать при проблемах с сервером и т.п. I>Ну все ж таки буду настаивать, что правильное поведение — ет считать автором того чувака, который авторизировался при пуше в репозитарий. У него кстате есть свой локальный репо, и при разборе полетов можно поднять историю по нему и посмотреть кто чего туда коммитил. И так далее по цепочке. По крайней мере ясно откуда ноги растут, кого пинать и в какой последовательности. I>Как вариант — иметь 2 поля, "автор ченджсета"(тут кто угодно может быть) и "автор пуша"(тут строго тот кто авторизировался).
В hg такое не умеет, насколько я знаю, а в git есть 2 поля — author и committer. А проверять можно в хуках. Есть hooks/update-paranoid скрипт, но я сам не пользовался.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, jazzer, Вы писали:
j> Ну конечно, "не верь глазам своим". Кто поставит? Кто назначит? Если в политике компании записано: "Веб-сервер — IIS", то кто-то должен будет взять на себя личную ответственность за нарушение полиси, либо взять на себя труд добиться официального ее изменения.
Бюрократию обойти можно. Апач можно запускать на порту >1024 как бэкенд и в IIS, как в фронтенде, прописать проксирование 80-го порта в апач.
Здравствуйте, rm822, Вы писали:
I>>Извините мой сарказм, но вы наверное не читатель? R>чего в svn-е не хватало
Та пожалуй всего положительного, чего есть в распределенных системах: коммитах хоть каждые 5 минут, без боязни поломать чужой функционал, возможность работать в оффлайне, простота работы с бранчами, продвинутый мерж, пересылка чейнджсетов напрямую между девелоперами... ну и конечно геморроя в дотачивании напильником этого хозяйства под наши требования в администрировании и секурити
I>Та пожалуй всего положительного, чего есть в распределенных системах:
Большая часть этого безобразия есть в перфорсе
-коммитах хоть каждые 5 минут, без боязни поломать чужой функционал
да, на стримах
-возможность работать в оффлайне
только для галочки, реально полный отстой
они считают это идеологически неверным ходом для _коммерческой_ разработки (и я с ними согласен)
-простота работы с бранчами
да, есть такое дело, прикрутили в последнем релизе
-продвинутый мерж
да, отличный
-пересылка чейнджсетов напрямую между девелоперами...
в принципе есть 3 возможности это сделать, в зависимости от целей. Но не напрямую а через центральный репозиторий — опять же — идеология
-ну и конечно геморроя в дотачивании напильником этого хозяйства под наши требования в администрировании и секурити
не зная требований сказать ничего нельзя
Здравствуйте, ., Вы писали:
.>Здравствуйте, jazzer, Вы писали:
j>> Ну конечно, "не верь глазам своим". Кто поставит? Кто назначит? Если в политике компании записано: "Веб-сервер — IIS", то кто-то должен будет взять на себя личную ответственность за нарушение полиси, либо взять на себя труд добиться официального ее изменения. .>Бюрократию обойти можно. Апач можно запускать на порту >1024 как бэкенд и в IIS, как в фронтенде, прописать проксирование 80-го порта в апач.
ну да, можно и зайца научить курить. Но, имхо, лучше бы разработчикам ХГ сделать нормальную интеграцию с IIS и Active Directory.
Здравствуйте, jazzer, Вы писали:
J>ну да, можно и зайца научить курить. Но, имхо, лучше бы разработчикам ХГ сделать нормальную интеграцию с IIS и Active Directory.
Да есть эта интеграция, сам IIS Много чего полезного не умеет. Ты предлагаешь не инетграцию сделать, а повторить в HG функционал Apache, потому что IIS туповат.
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, jazzer, Вы писали:
A>>>Из под рута только bind+listen+accept делается, реальная обработка запроса (recv/send) происходит в контексте www-data J>>Тем не менее сервер надо стартовать под рутом, не? А одно это — уже большая головная боль для любого безопасника, а уж плагинная система апача — это вообще одна большая дыра.
A>Да, первый процесс любого сервера слушающего порт ниже 1024 стартуется в Линуксе под рутом.
Ну так вот и получается, что ты хочешь установить прогу, которая будет запускаться под рутом.
Спроси Кочеткова, как он бы отнесся к этому.
A>>>Тот же кто SVN/TFS поменяет на HG. Я реально не поменяю почему замена VCS это меньшая проблема, чем добавление веб-сервера. J>>Очень просто. VCS обычно идет по графе Developer tools, вместе со всякими библиотеками и прочими решарперами, и рулится это обычно только отделом разработки с гораздо более мягкой политикой. А вот веб-сервер — это глобальная вещь, которая, в принципе, может смотреть наружу и дает доступ внутрь сети извне, и должна огораживаться с соответствующий строгостью.
A>Странные вещи говоришь. Вот sharepoint интегрированный с TFS (отдельный инстанс) это Developer Tools или нет? redmine, trac или bugzilla работающие под тем же Apache или как самостоятельные веб серверы это что?
Зависит от конторы. У каждой конторы своя политика на этот счет, от полного пофигизма до тотального огораживания.
A>Почему если программа случает на 80м порту то она сразу выпадает из списка Developer Tools?
Потому что апач стартует под рутом, в отличие от всех остальных, которые требуют веб-сервер как платформу, и поэтому требует специального рассмотрения с точки зрения безопасности.
И по-хорошему, все наиболее распространенные веб-сервера (Apache, IIS, lighttpd) должны поддерживаться "из коробки" или хотя бы в таком виде (по перечисленным), если просто инструкции достаточно: http://trac.edgewall.org/wiki/TracOnWindowsIis http://www.redmine.org/boards/1/topics/7412 http://lpsolit.wordpress.com/2010/10/22/make-bugzilla-work-with-iis7-easy/
Но однозначно лучше "из коробки".
J>>Ты вон и сам там рядом говорил "кастрированный апач, нельзя еще что-нть запустить" — что, очевидно, противоречит изначальной заявке "апач как неотъемлемая часть хг": тебе разрешишь поставить апач для хг, а ты на нем полноценный сервак развернешь и будешь секретные сорцы из дома выкачивать.
A>Я как кто? Я как админ и так всё домой унесу, я как программист Apache настраивать не смогу.
ты же хотел его настраивать, сам же говорил О отдел безопасности так просто разрешать установку веб-сервера не должен по-любому.
J>>Да я ж не спорю, что Апач лучше ИИСа. Я говорю только о том, что в корпоративном сегменте обычно не разрешают ставить что попало, и поэтому любой софт, который хочет в корпоративный сегмент пробиться, должен поддерживать то, что там чаще всего используется, и ИИС в этот список, разумеется, входит. А без этого это будет инструментов опенсорсников, о чем, в принципе, и говорят приведенные комменты его разработчиков.
A>Я ещё раз повторяю, не может быть такого чтобы человек пробил установку софта на каждую рабочую станцию (hg, TortoiseHG, VisualHG/HgScc) и не пробил установку Apache на один сервер, которым пользутся только разработчики. Проблема надумана. Правда. Честное программистское.
Я вообще не понимаю, о чем спор. Ты утверждаешь, что ХГ не должен себя утруждать нормальной поддержкой IIS? Что всем желающим его установить под винду лучше пободаться с апачем, линуксом в виртуалке (прости господи!) и своей местной бюрократией, если у них на работе IIS является вебсервером по умолчанию, чем просто установить то, что с IIS работает из коробки, а начальству аргументировать тем, что оно замечатльно интегрируется со всем, что у них сейчас, и не требует ничего лишнего, кроме собственно ХГ? Не понимаю твоей логики.
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, jazzer, Вы писали:
J>>ну да, можно и зайца научить курить. Но, имхо, лучше бы разработчикам ХГ сделать нормальную интеграцию с IIS и Active Directory.
A>Да есть эта интеграция, сам IIS Много чего полезного не умеет. Ты предлагаешь не инетграцию сделать, а повторить в HG функционал Apache, потому что IIS туповат.
Ну вообще-то да, именно это я и предлагаю. "Поддержка IIS" означает в том числе и поддержку его багов, и поддержку того, чего он не умеет.
И если они не хотят терять пользователей, котоые по любым независящим от них причинам должны сидеть на IIS, то им придется это сделать.
Другое дело, что им, похоже, по барабану.
Здравствуйте, jazzer, Вы писали:
J>Ну так вот и получается, что ты хочешь установить прогу, которая будет запускаться под рутом. J>Спроси Кочеткова, как он бы отнесся к этому.
jazzer, так работает подавляющее большинство публичных серверов в Интернете, почему это должно кого-то беспокоить в корпоративной сети?
A>>Странные вещи говоришь. Вот sharepoint интегрированный с TFS (отдельный инстанс) это Developer Tools или нет? redmine, trac или bugzilla работающие под тем же Apache или как самостоятельные веб серверы это что? J>Зависит от конторы. У каждой конторы своя политика на этот счет, от полного пофигизма до тотального огораживания.
И какой выход? IIS не поддерживает права доступа на основе регулярных выражений, применённых к URL. Ты предлагаешь из-за того что IIS что-то не поддерживает и в какой-то странной конторе странные политики безопасности разработчикам Mercurial полностью дублировать функциональность Apache? Ты понимаешь насколько нелепа как сама просьба, так и её мотивация?
J>Потому что апач стартует под рутом, в отличие от всех остальных, которые требуют веб-сервер как платформу, и поэтому требует специального рассмотрения с точки зрения безопасности.
Ты понимаешь, что поддержка IIS есть и проблема только в убогости самого IIS? HG под Apache умеет больше не потому что инетграция лучше, а потому что сам Apache умеет больше.
A>>Я как кто? Я как админ и так всё домой унесу, я как программист Apache настраивать не смогу. J>ты же хотел его настраивать, сам же говорил О отдел безопасности так просто разрешать установку веб-сервера не должен по-любому.
Я хотел его настраивать, потому что мне нужен не только для HG, вот и всё. Настраивать Фpache не самоцель.
J>Я вообще не понимаю, о чем спор. Ты утверждаешь, что ХГ не должен себя утруждать нормальной поддержкой IIS? Что всем желающим его установить под винду лучше пободаться с апачем, линуксом в виртуалке (прости господи!) и своей местной бюрократией, если у них на работе IIS является вебсервером по умолчанию, чем просто установить то, что с IIS работает из коробки, а начальству аргументировать тем, что оно замечатльно интегрируется со всем, что у них сейчас, и не требует ничего лишнего, кроме собственно ХГ? Не понимаю твоей логики.
Я утверждаю, что если контора враги сами себе, то никакой функционал HG их не спасёт. Использование Apache и безопасность вопросы вообще никак не связанные. И да, изначально линуксовский софт под Линуксом работает гораздо лучше и администрируется проще. И HG и Apache. Я и под windows их настраивал и под Linux, знаю о чём говорю.
Здравствуйте, jazzer, Вы писали:
J>Ну вообще-то да, именно это я и предлагаю. "Поддержка IIS" означает в том числе и поддержку его багов, и поддержку того, чего он не умеет. J>И если они не хотят терять пользователей, котоые по любым независящим от них причинам должны сидеть на IIS, то им придется это сделать. J>Другое дело, что им, похоже, по барабану.
Мне бы на их месте тоже было бы по барабану. Переезд на другую VCS это настолько серьёзное изменение, что установка Apache, Linux, вирутальный сервер капля в море на фоне всех необходимых работ.
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, jazzer, Вы писали:
J>>Ну так вот и получается, что ты хочешь установить прогу, которая будет запускаться под рутом. J>>Спроси Кочеткова, как он бы отнесся к этому.
A>jazzer, так работает подавляющее большинство публичных серверов в Интернете, почему это должно кого-то беспокоить в корпоративной сети?
Так это "большинство серверов" огорожено по самое не могу относительно того, до чего они могут дотянуться в интранете. Они вообще за дополнительным файрволом сидят в большинстве случаев. А твой апач для ХГ будет в самом сердце интранета сидеть, можно сказать.
A>И какой выход? IIS не поддерживает права доступа на основе регулярных выражений, применённых к URL. Ты предлагаешь из-за того что IIS что-то не поддерживает и в какой-то странной конторе странные политики безопасности разработчикам Mercurial полностью дублировать функциональность Apache? Ты понимаешь насколько нелепа как сама просьба, так и её мотивация?
Ну так ХГ-то больше известно о правах доступа внутри репозитария, чем просто регэкспы соответствующих урлов, не? Или там все отдано на откуп веб-сервера? Как же тогда их собственный сервер работает? Или у ХГ внутри вообще никаких прав нет нигде?
J>>Потому что апач стартует под рутом, в отличие от всех остальных, которые требуют веб-сервер как платформу, и поэтому требует специального рассмотрения с точки зрения безопасности.
A>В Линуксе все сервера слушающие порт с номером меньше 1024 стартуют под рутом. Нет только веб,вообще все. Так там сокеты работают.
Да, а еще 2+2=4. К чему этот ликбез для первоклассников, да еще и повторенный дважды?
К любой программе, стартующей под рутом, должны применяться повышенные требования безопасности. Точка.
A>Ты понимаешь, что поддержка IIS есть и проблема только в убогости самого IIS? HG под Apache умеет больше не потому что инетграция лучше, а потому что сам Apache умеет больше.
Я так изначально понял, что поддержки IIS нет и надо плясать с бубном, чтоб оно хоть как-то заработало.
A>>>Я как кто? Я как админ и так всё домой унесу, я как программист Apache настраивать не смогу. J>>ты же хотел его настраивать, сам же говорил О отдел безопасности так просто разрешать установку веб-сервера не должен по-любому. A>Я хотел его настраивать, потому что мне нужен не только для HG, вот и всё. Настраивать Фpache не самоцель.
Ну и возвращаемся к прежнему: ты вначале просишь разрешить установку апача для того, чтоб работал хг, а потом оказывается, что он тебе нужен еще для чего-то.
J>>Я вообще не понимаю, о чем спор. Ты утверждаешь, что ХГ не должен себя утруждать нормальной поддержкой IIS? Что всем желающим его установить под винду лучше пободаться с апачем, линуксом в виртуалке (прости господи!) и своей местной бюрократией, если у них на работе IIS является вебсервером по умолчанию, чем просто установить то, что с IIS работает из коробки, а начальству аргументировать тем, что оно замечатльно интегрируется со всем, что у них сейчас, и не требует ничего лишнего, кроме собственно ХГ? Не понимаю твоей логики.
A>Я утверждаю, что если контора враги сами себе, то никакой функционал HG их не спасёт. Использование Apache и безопасность вопросы вообще никак не связанные.
Ну конечно, еще одна прога, работающая под рутом, и безопасность — вопросы вообще никак не связанные. Кочеткова на тебя нет.
A>И да, изначально линуксовский софт под Линуксом работает гораздо лучше и администрируется проще. И HG и Apache. Я и под windows их настраивал и под Linux, знаю о чём говорю.
Было бы странно, если бы было наоборот
Здравствуйте, jazzer, Вы писали:
A>>jazzer, так работает подавляющее большинство публичных серверов в Интернете, почему это должно кого-то беспокоить в корпоративной сети? J>Так это "большинство серверов" огорожено по самое не могу относительно того, до чего они могут дотянуться в интранете.
Ты не поверишь, по этих файрволах, как правило, тоже Линукс. Пообщайся в форуме ИБ, лучше будет.
J>Ну так ХГ-то больше известно о правах доступа внутри репозитария, чем просто регэкспы соответствующих урлов, не? Или там все отдано на откуп веб-сервера? Как же тогда их собственный сервер работает? Или у ХГ внутри вообще никаких прав нет нигде?
Ни у Mercurial, ни у Git нет никаких fine grained прав доступа из коробки. Можно конкретному пользователю дать доступ read-only или read-write на весь репозиторий целиком. Причём в том что есть из коробки никаких групп пользователей, интегрированной аутентификации и т.д. тоже нет. Фактически да, всё что за пределами потребностей тестовой инсталляции отдано на откуп веб-сервера.
J>Да, а еще 2+2=4. К чему этот ликбез для первоклассников, да еще и повторенный дважды? J>К любой программе, стартующей под рутом, должны применяться повышенные требования безопасности. Точка.
Ещё раз отсылаю тебя в форум по ИБ.
J>Я так изначально понял, что поддержки IIS нет и надо плясать с бубном, чтоб оно хоть как-то заработало.
В режиме read-write для всех оно работает без проблем даже без выделенного веб-сервера.
J>Ну и возвращаемся к прежнему: ты вначале просишь разрешить установку апача для того, чтоб работал хг, а потом оказывается, что он тебе нужен еще для чего-то.
Например для trac или redmine. Apache это веб-платформа, он сам по себе вообще не нужен.
A>>Я утверждаю, что если контора враги сами себе, то никакой функционал HG их не спасёт. Использование Apache и безопасность вопросы вообще никак не связанные. J>Ну конечно, еще одна прога, работающая под рутом, и безопасность — вопросы вообще никак не связанные. Кочеткова на тебя нет.
Здравствуйте, jazzer, Вы писали:
A>>В Линуксе все сервера слушающие порт с номером меньше 1024 стартуют под рутом. Нет только веб,вообще все. Так там сокеты работают. J>Да, а еще 2+2=4. К чему этот ликбез для первоклассников, да еще и повторенный дважды? J>К любой программе, стартующей под рутом, должны применяться повышенные требования безопасности. Точка.
Ну поставь lighttpd и сделай проксирование на порт, скажем, 1080. Под которым и запускай Апач. Какие проблемы-то?
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, jazzer, Вы писали:
A>>>В Линуксе все сервера слушающие порт с номером меньше 1024 стартуют под рутом. Нет только веб,вообще все. Так там сокеты работают. J>>Да, а еще 2+2=4. К чему этот ликбез для первоклассников, да еще и повторенный дважды? J>>К любой программе, стартующей под рутом, должны применяться повышенные требования безопасности. Точка. C>Ну поставь lighttpd и сделай проксирование на порт, скажем, 1080. Под которым и запускай Апач. Какие проблемы-то?
lighttpd запускается под рутом и его надо разрешать
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, jazzer, Вы писали:
A>>>В Линуксе все сервера слушающие порт с номером меньше 1024 стартуют под рутом. Нет только веб,вообще все. Так там сокеты работают. J>>Да, а еще 2+2=4. К чему этот ликбез для первоклассников, да еще и повторенный дважды? J>>К любой программе, стартующей под рутом, должны применяться повышенные требования безопасности. Точка. C>Ну поставь lighttpd и сделай проксирование на порт, скажем, 1080. Под которым и запускай Апач. Какие проблемы-то?
То же самое. lighttpd должен быть уже разрешен к установке и запуску.
Здравствуйте, adontz, Вы писали:
A>>>jazzer, так работает подавляющее большинство публичных серверов в Интернете, почему это должно кого-то беспокоить в корпоративной сети? J>>Так это "большинство серверов" огорожено по самое не могу относительно того, до чего они могут дотянуться в интранете.
A>Ты не поверишь, по этих файрволах, как правило, тоже Линукс. Пообщайся в форуме ИБ, лучше будет.
Ты все еще со мной разговариваешь или сам с собой? А то мы вроде апач для ХГ обсуждаем, а ты то вдруг про Линукс заговоришь, то про публичные веб-сервера, то про сокеты...
J>>Ну так ХГ-то больше известно о правах доступа внутри репозитария, чем просто регэкспы соответствующих урлов, не? Или там все отдано на откуп веб-сервера? Как же тогда их собственный сервер работает? Или у ХГ внутри вообще никаких прав нет нигде?
A>Ни у Mercurial, ни у Git нет никаких fine grained прав доступа из коробки. Можно конкретному пользователю дать доступ read-only или read-write на весь репозиторий целиком. Причём в том что есть из коробки никаких групп пользователей, интегрированной аутентификации и т.д. тоже нет. Фактически да, всё что за пределами потребностей тестовой инсталляции отдано на откуп веб-сервера.
Тогда понятно.
J>>Да, а еще 2+2=4. К чему этот ликбез для первоклассников, да еще и повторенный дважды? J>>К любой программе, стартующей под рутом, должны применяться повышенные требования безопасности. Точка.
A>Ещё раз отсылаю тебя в форум по ИБ.
Задал вопрос там, посмотрим, что скажут.
J>>Я так изначально понял, что поддержки IIS нет и надо плясать с бубном, чтоб оно хоть как-то заработало. A>В режиме read-write для всех оно работает без проблем даже без выделенного веб-сервера.
ОК, для "как-то заработало" достаточно, согласен. Для серьезного промышленного использования, очевидно, нет.
J>>Ну и возвращаемся к прежнему: ты вначале просишь разрешить установку апача для того, чтоб работал хг, а потом оказывается, что он тебе нужен еще для чего-то.
A>Например для trac или redmine.
А так же для бэкдора какого-нть.
A>>>Я утверждаю, что если контора враги сами себе, то никакой функционал HG их не спасёт. Использование Apache и безопасность вопросы вообще никак не связанные. J>>Ну конечно, еще одна прога, работающая под рутом, и безопасность — вопросы вообще никак не связанные. Кочеткова на тебя нет. A>Пригласи сюда Кочеткова, кто же мешает?
Уже.
Здравствуйте, jazzer, Вы писали:
J>>>Да, а еще 2+2=4. К чему этот ликбез для первоклассников, да еще и повторенный дважды? J>>>К любой программе, стартующей под рутом, должны применяться повышенные требования безопасности. Точка. C>>Ну поставь lighttpd и сделай проксирование на порт, скажем, 1080. Под которым и запускай Апач. Какие проблемы-то? J>То же самое. lighttpd должен быть уже разрешен к установке и запуску.
А что-нибудь вообще есть разрешённое-то?
Блин, ну тогда можно поставить Меркуриал на 8080 и везде в URL'ах репозитория указывать его. Будет работать.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, jazzer, Вы писали:
J>>>>Да, а еще 2+2=4. К чему этот ликбез для первоклассников, да еще и повторенный дважды? J>>>>К любой программе, стартующей под рутом, должны применяться повышенные требования безопасности. Точка. C>>>Ну поставь lighttpd и сделай проксирование на порт, скажем, 1080. Под которым и запускай Апач. Какие проблемы-то? J>>То же самое. lighttpd должен быть уже разрешен к установке и запуску. C>А что-нибудь вообще есть разрешённое-то?
IIS + Active Directory
C>Блин, ну тогда можно поставить Меркуриал на 8080 и везде в URL'ах репозитория указывать его. Будет работать.
Речь не о том, как извернуться, чтоб заработало
Здравствуйте, itslave, Вы писали:
I>Здравствуйте, rm822, Вы писали:
I>(поскипано) I>Я рад что в перфорсе все хорошо
в перфорсе все так хорошо что будете по свну рыдать кровавыми слезами. Я вот 4 месяца уже так.
а насчет авторства чейнджей там проблему вы не поняли. Речь идет о том что у разработчика есть локальный репо в нем он сам себе царь и может править историю как хочет. И то что он заливает на сервер как правило содержит кучу чужих чейнджсетов полученных от других разработчиков мимо кассы. Иначе вам нет смысла держать офис так как каждый может сидеть дома и не общаясь ни с кем делать свои таски. И соответственно ставить авторство на чужие чейнджи есть дикость и никто в опенсорсе так делать не будет. Если вы осуществите свою мечту то у вас в центральном репо будет один автор — тот кто мержил весь этот бардак. Я регулярно был таким "мержером по вызову" так что знаю что большинство разработчиков пасуют при виде многопутевых мержей с попутанной историей и 2-3 раза наложенными чужими патчами так как они пришли разными путями.
Здравствуйте, itslave, Вы писали:
I>Здравствуйте, A13x, Вы писали:
A>>Здравствуйте, itslave, Вы писали:
I>>>...
A>>На работе в свое время перешли на git и еще ни разу не пожалели. Правда часть сидит на linux, часть на mac. A>>Интеграция с JIRA отличная, все работает на ура, с бинариками вроде проблем не было особых.
A>>Что там не так с гитом? I>Если пользователь делает push в репозитарий, который требует аутентификации, можно ли быть уверенным что в качестве автора изменений будет логин, под которым пользователь аутентифицировался?
Да, можно. push сводится к набору операций осуществляемых через ssh. Если вы не знаете логина и пароля / ключа (в зависимости от способа аутентификации), то не сможете закоммитить изменения якобы из под другого пользователя.
Здравствуйте, SleepyDrago, Вы писали:
SD>Здравствуйте, itslave, Вы писали:
I>>Здравствуйте, rm822, Вы писали:
I>>(поскипано) I>>Я рад что в перфорсе все хорошо SD>в перфорсе все так хорошо что будете по свну рыдать кровавыми слезами. Я вот 4 месяца уже так.
Ну я просто за человека порадовался, нельзя чтоли?
SD>а насчет авторства чейнджей там проблему вы не поняли. Речь идет о том что у разработчика есть локальный репо в нем он сам себе царь и может править историю как хочет. И то что он заливает на сервер как правило содержит кучу чужих чейнджсетов полученных от других разработчиков мимо кассы. Иначе вам нет смысла держать офис так как каждый может сидеть дома и не общаясь ни с кем делать свои таски. И соответственно ставить авторство на чужие чейнджи есть дикость и никто в опенсорсе так делать не будет. Если вы осуществите свою мечту то у вас в центральном репо будет один автор — тот кто мержил весь этот бардак. Я регулярно был таким "мержером по вызову" так что знаю что большинство разработчиков пасуют при виде многопутевых мержей с попутанной историей и 2-3 раза наложенными чужими патчами так как они пришли разными путями.
Тут уже обсудили и пришли к выводу(по крайней мере я) что в чейнджсете необходимо еще одно поле, что-то типа "commiter" в которое пишется аутентификационная инфа того человека, который залил данный чейнджсет в данный репозитарий. Ессна в разных репозитариях эта инфа должна меняться.
А то что предлагает hg "из коробки" — ет извините детский лепет, как по этой "истории" проводить разбор полетов я даже не представляю.
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, itslave, Вы писали:
I>>Стандартный увы то что надо не делает. Похожих примеров(конкретно вытаскивание аутентификационной инфы) я не нашел, может плохо искал.
A>Я ошибся, хук нужен не incoming, а pretxnchangegroup
A>[hooks] A>pretxnchangegroup = /path/to/script
A>вот такой вот баш скрипт хука A>
A>echo ${HG_URL:14} #отрезал первые 14 символов
A>hg log -r $HG_NODE --template "{author}" $PWD
A>
A>выдаёт мне имя аутентифицированного пользователя и имя из лога. Дальше их надо сравнить и вернуть не 0 если надо прервать операцию. пример развивать не стал, так как вы CMD или Powershell будете использовать.
Спасибо за наводку, еще полдня нанайских народных танцев и курения мануалов и все получилось: решил вешать уникальный таг, содержащий имя "пушера" на каждый ченджсет. Дешыва и сердита.
Здравствуйте, itslave, Вы писали:
I>А то что предлагает hg "из коробки" — ет извините детский лепет, как по этой "истории" проводить разбор полетов я даже не представляю.
Реально более нужно криптографическое подписывание коммитов (в том числе и merge'ей). В git'е это недавно нормально запилили.
Здравствуйте, A13x, Вы писали:
A>>>Что там не так с гитом? I>>Если пользователь делает push в репозитарий, который требует аутентификации, можно ли быть уверенным что в качестве автора изменений будет логин, под которым пользователь аутентифицировался? A>Да, можно. push сводится к набору операций осуществляемых через ssh. Если вы не знаете логина и пароля / ключа (в зависимости от способа аутентификации), то не сможете закоммитить изменения якобы из под другого пользователя.
А это где нить запоминается и можно легко и непринужденно увидеть, кто же запушил в репозиторий конкретно взятый ченджсет?
Здравствуйте, itslave, Вы писали:
I>Здравствуйте, SleepyDrago, Вы писали:
SD>>Здравствуйте, itslave, Вы писали:
I>>>(поскипано)
SD>>а насчет авторства чейнджей там проблему вы не поняли. Речь идет о том что у разработчика есть локальный репо в нем он сам себе царь и может править историю как хочет. И то что он заливает на сервер как правило содержит кучу чужих чейнджсетов полученных от других разработчиков мимо кассы. Иначе вам нет смысла держать офис так как каждый может сидеть дома и не общаясь ни с кем делать свои таски. И соответственно ставить авторство на чужие чейнджи есть дикость и никто в опенсорсе так делать не будет. Если вы осуществите свою мечту то у вас в центральном репо будет один автор — тот кто мержил весь этот бардак. Я регулярно был таким "мержером по вызову" так что знаю что большинство разработчиков пасуют при виде многопутевых мержей с попутанной историей и 2-3 раза наложенными чужими патчами так как они пришли разными путями. I>Тут уже обсудили и пришли к выводу(по крайней мере я) что в чейнджсете необходимо еще одно поле, что-то типа "commiter" в которое пишется аутентификационная инфа того человека, который залил данный чейнджсет в данный репозитарий. Ессна в разных репозитариях эта инфа должна меняться. I>А то что предлагает hg "из коробки" — ет извините детский лепет, как по этой "истории" проводить разбор полетов я даже не представляю.
я ненавязчиво намекаю что в этом поле продакшна как правило будет одно и то же имя (ну или 2-3 в зависимости от отпусков и личного состава). Те кто проводил интеграцию. У нас сейчас в перфорсе нет никакой аутентификации — имя человека пишется исключительно для display и никак не проверяется. Если вы не готовы доверять тому что коллектив мотивирован в успехе проекта у вас нет ни одного шанса быть более умным чем коллектив разработчиков. Это справедливо для любой штучной разработки /имхо.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, itslave, Вы писали:
I>>А то что предлагает hg "из коробки" — ет извините детский лепет, как по этой "истории" проводить разбор полетов я даже не представляю. C>Реально более нужно криптографическое подписывание коммитов (в том числе и merge'ей). В git'е это недавно нормально запилили.
А можно поподробней(или линку на годную статтю), интересно стало.
В первую очередь интересует в контексте как это поможет узнать кого раком ставить.
Здравствуйте, SleepyDrago, Вы писали:
SD>я ненавязчиво намекаю что в этом поле продакшна как правило будет одно и то же имя (ну или 2-3 в зависимости от отпусков и личного состава). Те кто проводил интеграцию.
А интегрировать они будут из воздуха, или же у них каким то образом появятся чейнджсеты, которые собственно говоря и надо синтегрировать в релизную ветку? Следующий шаг — формализовать обмен чейнджсетов между девами и интеграторами. А ет либо какой нить промежуточный репозитарий либо емейл — все решается
SD>У нас сейчас в перфорсе нет никакой аутентификации — имя человека пишется исключительно для display и никак не проверяется. Если вы не готовы доверять тому что коллектив мотивирован в успехе проекта у вас нет ни одного шанса быть более умным чем коллектив разработчиков. Это справедливо для любой штучной разработки /имхо.
На одном прянике далеко не уедешь.
Ты подходишь к Mercurial с мерками централизованных систем контроля версий. А она так не работает. Типичный процесс: Вася реализовал какую-то функциональность, Петя взял Васины коммиты напрямую у него и на их основе сделал что-то еще, после чего произвел push в общий репозиторий. Получается, аутентифицировался Петя, но отправил в числе прочего Васины коммиты.
Проблема решается цифровыми подписями, причем тегов, а не коммитов. Подпись, удостоверяющая, что этот коммит внесен таким-то пользователем, ничего не значит. Может, это эксперимент, который не должен был попадать в общий репозиторий, а недоброжелатель его всё равно туда запустил. Подписанная метка, обещающая, что коммит достигает какой-то цели, — совсем другое дело.
Здравствуйте, Roman Odaisky, Вы писали:
RO>Ты подходишь к Mercurial с мерками централизованных систем контроля версий. А она так не работает. Типичный процесс: Вася реализовал какую-то функциональность, Петя взял Васины коммиты напрямую у него и на их основе сделал что-то еще, после чего произвел push в общий репозиторий. Получается, аутентифицировался Петя, но отправил в числе прочего Васины коммиты.
Да неважно откуда Петя взял данные: с гугля, у Васи, из головы. Важно то что именно Вася запостил их не проверив в центральный репозитарий. Значит в случае чего он должен огрести.
RO>Проблема решается цифровыми подписями, причем тегов, а не коммитов. Подпись, удостоверяющая, что этот коммит внесен таким-то пользователем, ничего не значит. Может, это эксперимент, который не должен был попадать в общий репозиторий, а недоброжелатель его всё равно туда запустил. Подписанная метка, обещающая, что коммит достигает какой-то цели, — совсем другое дело.
Здравствуйте, itslave, Вы писали:
I>Да неважно откуда Петя взял данные: с гугля, у Васи, из головы. Важно то что именно Вася запостил их не проверив в центральный репозитарий. Значит в случае чего он должен огрести.
Понятно. Вот для этого в git есть committer и author.
I>И ето есть в меркурале? Или просто мечты в слух? http://mercurial.selenic.com/wiki/CommitsigsExtension
А в git искаропки. hg — must die.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, itslave, Вы писали:
I>>>А то что предлагает hg "из коробки" — ет извините детский лепет, как по этой "истории" проводить разбор полетов я даже не представляю. C>>Реально более нужно криптографическое подписывание коммитов (в том числе и merge'ей). В git'е это недавно нормально запилили. I>А можно поподробней(или линку на годную статтю), интересно стало. I>В первую очередь интересует в контексте как это поможет узнать кого раком ставить.
Стоит понимать, что в git/hg вполне допустима ситуация, когда я возьму коммиты Пети и закоммичу их от своего имени. При это в логе будет так и записано "автор — Петя, закоммичено Васей". Это абсолютно штатная ситуация, хотя её можно запретить административно, повесив хуки на центральный репозиторий, которые проверяют авторство.
Но гораздо лучше эту ситуацию обратить в свою пользу. Для этого вводится криптографическое подписывание коммитов, и в логе будет записано нечто типа "автор — Петя <цифровая подпись коммита>, закоммичено Васей <цифровая подпись merge-коммита>". Так что по подписям можно всегда восстановить историю, даже если merge осуществлялся через несколько посредников.
Это гораздо более сильная гарантия, так как подпись без получения доступа к приватным ключам всех в цепочке подделать невозможно. Тогда как зловредный администратор может зайти на центральный хостинг и туда чего-нибудь левое добавить.
В git озаботились подписыванием после недавней компрометации сайта kernel.org.
Здравствуйте, itslave, Вы писали:
I>Спасибо за наводку, еще полдня нанайских народных танцев и курения мануалов и все получилось: решил вешать уникальный таг, содержащий имя "пушера" на каждый ченджсет. Дешыва и сердита.
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, itslave, Вы писали:
I>>Спасибо за наводку, еще полдня нанайских народных танцев и курения мануалов и все получилось: решил вешать уникальный таг, содержащий имя "пушера" на каждый ченджсет. Дешыва и сердита.
A>Выложи скрипт на публику, не жмоться
Та там того скрипта 5 строк, большы времени заняли эксперименты и раздумываняи как луччи связать ченджсет с инфой об аутентификации(и соотвественно чтение доки, размышлизмы).
Решил именна тагом потому как их видно прям в вебморде и ничего дописывать не надо(в принципе мона просто в логи(БД) фигачить и прикрутить веб страничку для поиска по этим логам).
В hgrc репозитария пишем
С какого то перепугу Powershell запускаться не захотел(можы прав системному иис-овскому аккаунту не хватает можы еще чего), а я уже замахалси и забил. Поентому ограничилси бат-скриптом(и опять жы время на чтение доки, 100 лет уже бат скриптов не писал и эксперименты)
set str=%HG_URL%
set str=%str%_%date%
set str=%str%_%time%
set str=%str::=_%
set str=%str:5C=_%
set str=%str:/=_%
set str=%str:.=_%
set str=%str: =_%
cd c:\Repositories\%1
call "c:\Program Files\Mercurial\hg.exe" tag -l -r %HG_NODE% %str%
(дата-время необходима для уникальности тагов, т.е. чтобы они не "перескакивали" на свежий чейнджсет того же пользователя).
Оно конечно кривенько но вся необходимая инфа есть и работает. Будет настроение — причешу.
Ышо таг делаем с ключем -l чтобы эти таги не расползались по "локальным" репозиториям, они там ни к чему имха.
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, itslave, Вы писали:
A>У меня вашей оранизационной проблемы нет, но я постараюсь в ближайшем будущем написать аналогичный bash скрипт и выложить здесь (ну и у себя внедрю)
Рассказали мне в этой теме про подписи чейнджсетов. Таки действительно, сила. Но, опять жы, хочется интеграцию в АД, централизированный менеджмент юзеров — ет реально очень удобно.
Вот я прям щас думаю, что идеально было бы:
1. При создании АД-пользователя автоматически создается сертификат, который прикрепляется к свойствам этого пользователя.
2. При коммите специальный хук определяет что за пользователь залогинен и подписывает чейнджсет его сертификатом, автоматически и прозрачно.
3. В настройках "центрального" репозитория прописывается чейнджсеты какой группы пользователей етот самый репозиторий может принимать
4. При пуше в "центральный" репозиторий проверяются цифровые подписи каждого чейнджсета
4.1 если ее нету — в сад
4.2 если сертификат, которым подписывали, не принадлежит ни одному пользователю из указанной в п.3 группы — тожы в сад.
Но я фактически уверен, что ничего подобного под hg не написано и не планируется в ближайшем будущем, поентому думаю ограничиться ручной генерацией ключей и выдачей их сотрудникам(хотя опять жы, неизвестно, можно ли аннулировать ключ если сотрудник увольняется).
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, itslave, Вы писали:
A>Это вам свой CA по идее нужен, иначе сертификаты отзывать не получится.
Т.е. решение, основанное исключительно на сертификатах мягко говоря не канает. Нужно сертификаты ассоциировать с локальными ресурсами, которыми можно управлять.
I>поставить-настроить под винду I>желательно IIS в качестве веб сервиса I>аутентификация-авторизация через Active Directory(изначально я вычитал что авторизация с расстановкой прав доступа — не получится) I> http://hglabhq.com/
HgLab: Mercurial Server and Repository Management for Windows
Здравствуйте, itslave, Вы писали:
I>Вот подумываю свалить обратно на SVN(в первую очередь из-за полного произвола в авторстве ченджсетов). Неделя приседаний коту под хвост. У git-а говорят все еще печальней с точки зрения настройки-интеграции. Про bazaar даже не вспоминаю.
TFS? Благо на "попробовать" много времени не надо. В связи с http://tfs.visualstudio.com/ пробовать стало еще проще — все серверные проблемы перенял МС.
Здравствуйте, jazzer, Вы писали:
A>>Большая часть ваших проблем от того что вы решили всё прикрутить к IIS. J>Странный подход... А если IIS — корпоративный стандарт и нельзя больше ничего, кроме него? J>У IIS не такая маленькая доля на рынке, особенно в корпоративном сегменте, чтоб называющийся серьезным софт мог на него забивать
Блин, ребят, ну вы даёте. Apache vs IIS против hgweb.cgi который, извинияюсь *** хотел ложить и на первого и второго.
На IIS ставится hg вообще без проблем. При том, я использую такую некузявую конфигурацию — разрешен basic и windows auth, браузером — пожалуйста виндовс ауф, — хг — видимо басик. Я давно не переконфигурял. Из дома я вот с битбаткетом работают через ssh. Это клёво. Только это хрень собачья, потому что это тоже самое должно работать за прокси, а оно не работает, ибо SSH!
IIS vs Apache из всего этого — наименьшая проблема.
Здравствуйте, itslave, Вы писали:
I>Да. Это может потребоваться один раз в 20 лет, но тогда это действительно понадобится. На моей практике был капитальный один разбор по сорцам годичной давности, с твердым намерением "уволить виноватого". Но виноватый этого разбора не дождался и свалил за несколько месяцев до него.
Так это саботаж был или нет? Мне почему-то кажется, что год назад этот парень никак не думал комитить эти исходники под чужим именем.
Обычно для таких случаев достаточно хранить логи, кто и с какого компьютера засунул изменения в основной репо и если человек утверждает, что комит с его именем делал не он — просто поднять их.
Здравствуйте, rm822, Вы писали:
R>Большая часть этого безобразия есть в перфорсе
R>-возможность работать в оффлайне R>только для галочки, реально полный отстой R>они считают это идеологически неверным ходом для _коммерческой_ разработки (и я с ними согласен)
Вот я занимаюсь вполне себе коммерческой разработкой и при этом не вижу никакой реальной причины на каждый чих связываться с сервером.
Если я разрабатываю какую-то фичу, я могу её коммитить хоть сидя на даче без интернета месяц по строке, потом перегруппировать локальные коммиты, сделать rebase на свежий код и потом наконец отправить на review (где мы сейчас на gerrit'е), или просто запушить, если простой центральный. Нафига мне при этом в процессе именно разработки связь с центром?
Объясните, пожалуйста.
Здравствуйте, jazzer, Вы писали:
J>>>Это, конечно, тоже вариант, но я бы лично его не разрешил, учитывая, что апач может шариться несколькими подобными инсталляциями (например, какая-нть вики тоже потребует своего апача — и чего?) и рассматривал бы отдельно апач и отдельно меркуриал. Не говоря уже о том, что апач на 80 порте должен работать из-под рута. A>>Из под рута только bind+listen+accept делается, реальная обработка запроса (recv/send) происходит в контексте www-data J>Тем не менее сервер надо стартовать под рутом, не?
Вообще-то это уже с надцать лет не так, и не только в Linux. Все расширенные системы безопасности (а в любом современном дистрибутиве есть какая-то из них, чаще всего) позволяют произвольный доступ. Например, вот базовые описания для SELinux (см. субкоманду port) и grsec базовое описание, как разрешать доступ конкретной программе без рута. В BSD, включая MacOS, есть MAC инфраструктура для того же. То, что установки "из коробки" по умолчанию не делают этого, не значит, что его нет.
А ещё никто не мешает, например, ввести в локальный iptables правило вида -t nat -p tcp --dport 80 -j REDIRECT --to-ports 8000, и все входящие TCP на порт 80 пойдут (в данном примере) на порт 8000.
Так что прошу не делать сейчас выводы из знания матчасти на 20 лет назад.
J>А одно это — уже большая головная боль для любого безопасника, а уж плагинная система апача — это вообще одна большая дыра.
Плагинная система апача инициализируется ещё до принятия конкретных запросов, а принимает запросы после сокращения прав. Так что здесь она не в состоянии ничего испортить. Если стартовые конфиги не испорчены, то максимум вреда от неё всё равно ограничен пользователем, под которым идёт работа.
Если что-то тут и вредит, то политика suexec'ов (например, в Debian он ужесточён в совершенно бессмысленную сторону).
A>>Тот же кто SVN/TFS поменяет на HG. Я реально не поменяю почему замена VCS это меньшая проблема, чем добавление веб-сервера. J>Очень просто. VCS обычно идет по графе Developer tools, вместе со всякими библиотеками и прочими решарперами, и рулится это обычно только отделом разработки с гораздо более мягкой политикой. А вот веб-сервер — это глобальная вещь, которая, в принципе, может смотреть наружу и дает доступ внутрь сети извне, и должна огораживаться с соответствующий строгостью.
Если developer tool, а конкретно, VCS требует доступа снаружи (а часто это так и есть), то у неё возникают такие же проблемы.
A>>Это IIS говорит — хрен вам, а не гибкая авторизация. И уже отсюда возникает вопрос об Apache. А Mercurial просто не дублирует то что Apache и так делает хорошо. J>Да я ж не спорю, что Апач лучше ИИСа. Я говорю только о том, что в корпоративном сегменте обычно не разрешают ставить что попало, и поэтому любой софт, который хочет в корпоративный сегмент пробиться, должен поддерживать то, что там чаще всего используется, и ИИС в этот список, разумеется, входит. А без этого это будет инструментов опенсорсников, о чем, в принципе, и говорят приведенные комменты его разработчиков.
Тогда тот же IIS должен, кроме формального выполнения под ним, обеспечивать ограничения исполняемого. А это уже далеко не всегда возможно. По современному состоянию проще запустить виртуалку, ограничив ей доступ даже в локалку только безусловно необходимым.
Здравствуйте, itslave, Вы писали:
RO>>Ты подходишь к Mercurial с мерками централизованных систем контроля версий. А она так не работает. Типичный процесс: Вася реализовал какую-то функциональность, Петя взял Васины коммиты напрямую у него и на их основе сделал что-то еще, после чего произвел push в общий репозиторий. Получается, аутентифицировался Петя, но отправил в числе прочего Васины коммиты. I>Да неважно откуда Петя взял данные: с гугля, у Васи, из головы. Важно то что именно Вася запостил их не проверив в центральный репозитарий. Значит в случае чего он должен огрести.
Нет, Вася не отправлял их туда, в том-то и дело!
1. Вася реализует нечто, как proof-of-concept. Коммитит в свой локальный репозиторий, и, возможно, в отдельную особо отмеченную ветку центрального репозитория.
2. Петя видит, что Васина работа поможет ему решить стоящую перед ним задачу. Он берет Васины коммиты (полностью или частично) и на их основе делает что-то свое.
3. Петина работа готова. Он прогоняет тесты, вешает тег о том, что такой-то тикет закрыт, подписывает и то ли сам коммитит в основную ветку центрального репозитория, то ли посылает pull request специально обученному человеку.
Вдруг что пошло не так — Вася никогда не обещал, что его код на 100% готов и работоспособен. А вот Петя берет на себя такую ответственность.
И еще, если система безопасности смотрит только на автора коммита, то можно провести replay attack — взять какой-нибудь промежуточный недоделанный коммит, вносящий уязвимость, и закоммитить в основную ветку от имени автора.
A>>>>В Линуксе все сервера слушающие порт с номером меньше 1024 стартуют под рутом. Нет только веб,вообще все. Так там сокеты работают. J>>>Да, а еще 2+2=4. К чему этот ликбез для первоклассников, да еще и повторенный дважды? J>>>К любой программе, стартующей под рутом, должны применяться повышенные требования безопасности. Точка. C>>Ну поставь lighttpd и сделай проксирование на порт, скажем, 1080. Под которым и запускай Апач. Какие проблемы-то?
Я наверное сейчас очень глупый вопрос задам, но что мешает запустить этот многострадальный апач на порту выше 1024 не под рутом? И не страдать с безопасностью?
I>Т.е. люди не понимают что ревью ченджсетов(регулярное или из-за факапа) — ет таки отвественная процедура, по результатам которой нахомутавший может огрести по самое не могу, вплоть до увольнений в особо запущенных случаях. И кодревьюеру надо просто и ясно видеть, кто запушил чейнджсет в репозитарий. I>Но мое мнение о hg осталось неизменно: для корпоративной бизнес разработке в среде windows он не годится.
В subversion "имя пользователя", который сделал коммит — это revision property, изменения которого не трекаются. Да, по умолчанию оно отключено — но если речь идет о саботаже и увольнении, то поменять задним числом не так трудно.
Тут вы, на мой взгляд, столкнулись с архитектурным вопросом. Subversion — централизованный репозиторий. Коммитера можно поменять задним числом, если есть доступ к репозиторию. Mercurial — у каждого репозиторий. Коммитера можно поменять... ну вы поняли . Поэтому с точки зрения безопасности в subversion от диверсий защищаются, блокируя репозиторий от нежелательных модификаций (и это ключено по умолчанию). В mercurial защищаются точно также — блакируют центральный репозиторий от нежелательных модификаций. Так как какой репозиторий "центральный" назначаете вы — то и хук на проверку стаить вам. Плата за гибкость .
Здравствуйте, Eye of Hell, Вы писали:
EH> I>Т.е. люди не понимают что ревью ченджсетов(регулярное или из-за факапа) — ет таки отвественная процедура, по результатам которой нахомутавший может огрести по самое не могу, вплоть до увольнений в особо запущенных случаях. И кодревьюеру надо просто и ясно видеть, кто запушил чейнджсет в репозитарий. EH> I>Но мое мнение о hg осталось неизменно: для корпоративной бизнес разработке в среде windows он не годится. EH> В subversion "имя пользователя", который сделал коммит — это revision property, изменения которого не трекаются. Да, по умолчанию оно отключено — но если речь идет о саботаже и увольнении, то поменять задним числом не так трудно.
Кстати да, от саботажа hg/git защищены гораздо лучше. В случае svn достаточно получить доступ к центральному репозиторию, чтобы всё нахакать как нравится — комар носу не подточит. А в случае hg/git незаметно историю поменять задним числом невозможно — поменяются все sha1 идентификаторы всех коммитов после, что вызовет полный ах во всех клонах, в логах билд серверов, в версиях артефактов, и т.п. А sha1 криптоустойчивый хеш, кстати говоря. А ещё pgp-подписи тегов есть...
Здравствуйте, jazzer, Вы писали:
j> A>Большая часть ваших проблем от того что вы решили всё прикрутить к IIS. j> Странный подход... А если IIS — корпоративный стандарт и нельзя больше ничего, кроме него?
Тогда количество приемлемых вариантов резко сужается до продуктов MS.
j> У IIS не такая маленькая доля на рынке, особенно в корпоративном сегменте, чтоб называющийся серьезным софт мог на него забивать
Попробуй посмотреть на это с другой стороны: "У mercurial не такая маленькая доля на рынке, чтобы называющийся серьезным веб-сервер мог на него забивать" — сказка о курице и яйце. mercurial прекрасно работает в корпоративном сегменте, если этот корпоративный сегмент готов его принять. Вы пока не можете — ну чтож, это не фатально — используйте TFS или любой другой продукт, к которому вы пока готовы — в этом и вся прелесть свободы выбора.
hg — must die.
.
