Добрейшего.
Некоторое время назад наткнулся на заметку в справке Google Code, посвященную тому, как выбирали распределённую систему контроля версий для этого проекта. Ссылка давно ждала удобного повода, но его не нашлось, так что лучше поздно, чем никогда.
С самого начала своей работы проект Google Code поддерживал только Subversion. Надо полагать, в виду его распространённости - ведь после заката CVS именно он стал стандартом де-факто среди бесплатных систем контроля версий. Проблемой выбора распределённой VCS команда озадачилась в 2008 году, в результате чего появилось вот это эссэ: Analysis of Git and Mercurial. Для тех, кто до сих пор поленился хоть немного изучить английский, есть народный перевод. Несмотря на мелкие неточности и стилистические ошибки, вполне можно понять, о чём речь.
Как видно на сайте Гугл.Кода, выбор пал на Ртутного. Причины - в тексте. Также встречал примерно следующее мнение - мол, приверженцы Subversion обитают на SourceForge, фанаты git - на github, ну и Гугл решил в чужой огород не лезть и взял под крыло Hg. Почему бы нет. К тому же, Python, на котором написана бОльшая часть Hg, весьма любим в компании.
P.S. Первый же коммент к оригинальному тексту вопрошает - почему Bazaar даже не рассматривали? Думаю, в первую очередь из-за его меньшей распространённости. Однако, прочитав очередной Bazaar hate speech, подумал, что не только поэтому :) Хотя это субъективное мнение, конечно.
Update: git таки появился среди поддерживаемых систем, не прошло и полгода: http://code.google.com/p/support/wiki/ChoosingAVersionControlSystem
Некоторое время назад наткнулся на заметку в справке Google Code, посвященную тому, как выбирали распределённую систему контроля версий для этого проекта. Ссылка давно ждала удобного повода, но его не нашлось, так что лучше поздно, чем никогда.
С самого начала своей работы проект Google Code поддерживал только Subversion. Надо полагать, в виду его распространённости - ведь после заката CVS именно он стал стандартом де-факто среди бесплатных систем контроля версий. Проблемой выбора распределённой VCS команда озадачилась в 2008 году, в результате чего появилось вот это эссэ: Analysis of Git and Mercurial. Для тех, кто до сих пор поленился хоть немного изучить английский, есть народный перевод. Несмотря на мелкие неточности и стилистические ошибки, вполне можно понять, о чём речь.
Как видно на сайте Гугл.Кода, выбор пал на Ртутного. Причины - в тексте. Также встречал примерно следующее мнение - мол, приверженцы Subversion обитают на SourceForge, фанаты git - на github, ну и Гугл решил в чужой огород не лезть и взял под крыло Hg. Почему бы нет. К тому же, Python, на котором написана бОльшая часть Hg, весьма любим в компании.
P.S. Первый же коммент к оригинальному тексту вопрошает - почему Bazaar даже не рассматривали? Думаю, в первую очередь из-за его меньшей распространённости. Однако, прочитав очередной Bazaar hate speech, подумал, что не только поэтому :) Хотя это субъективное мнение, конечно.
Update: git таки появился среди поддерживаемых систем, не прошло и полгода: http://code.google.com/p/support/wiki/ChoosingAVersionControlSystem
Дак для hg вроде в то же время родился bitbucket
ОтветитьУдалитьВот бы bitbucket на bazaar перешёл, для смеха )
ОтветитьУдалить2Qrilka
ОтветитьУдалитьНу, что то же надо было в конце концов выбрать :) Где bitbucket, и где гугл? :)
2lux_place
Разнообразие хостеров оупенсорса отражает общее разнообразие мира OS :) Так что вполне ожидаемо появление ещё как минимум пары-тройки хостеров git ил Hg :)
Юрий, у меня такой вопрос по Mercurial (HG):
ОтветитьУдалитьможно-ли на боевом сервере в корневой папке хранить файл .hg с версиями файлов?
Другими словами, можно-ли репозиторий делать из корневой папки?
Если нет, то как это правильнее решается?
Если под корнем понимается DocumentRoot - то, надо или делать "чистый" экспорт, или после клонирования убивать дирку, или (что оптимальнее) делать через конфиг веб-сервера эту директорию недоступной по http.
ОтветитьУдалитьЕсли же эта дирка на ружу в принципе не видится - то можно и не заморачиваться.
Спасибо!
ОтветитьУдалитьА "чистый" экспорт это что имеется в виду?
Я имею в виду экспорт, при котором не происходит создание служеюных папок.
ОтветитьУдалить