В общим и целом, начитавшись про то какие хорошие распределенные системы контроля версий и поигравшись тестовыми проектами, я решил перевести рабочий проект со старого проверенного 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 он не годится.
