Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 123
Подскажите можно ли где-то купить печатную версию SVNbook желательно на русском?
можно распечатать svnbook.red-bean.com/nightly/ru/
svnbook.red-bean.com/nightly/ru/svn-book.html
Русский перевод. Неполный и устаревший, так что учите английский.
Русский перевод. Неполный и устаревший, так что учите английский.
Эх, боюсь SVN, служивший мне верой и правдой несколько лет, ждёт история CVS… ибо git или mercurial рулят.
Чем рулят? Я понимаю священные войны и все такое, но статью SVN vs. GIT никто писать не хочет.
Да, ладно вам, забыл смайлик поставить и уже разжигают тут священные войны :)
А что писать то? Размер репозитария, распределенность и скорость работы. Этого не достаточно?
И это все? Ну тогда понятно что даже смотреть в эту сторону не буду.
гык
то есть если Вам один человек некомпетентно что-то рассказал — Вы не будете пользоваться существенно более мощным решением? :)
это в принципе даже хорошо, меньше конкуренции
если серьезно, то Git с концептуальной точки зрения делает Subversion на всех возможных уровнях.
на Svn есть очень чёткий потолок сложности
в Git его нету :)
то есть если Вам один человек некомпетентно что-то рассказал — Вы не будете пользоваться существенно более мощным решением? :)
это в принципе даже хорошо, меньше конкуренции
если серьезно, то Git с концептуальной точки зрения делает Subversion на всех возможных уровнях.
на Svn есть очень чёткий потолок сложности
в Git его нету :)
Подробнее можно? Нет ну извините за настойчивость, я понимаю что всегда хочется популяризировать что-то чем пользуешься сам, но если вы уж пишете комментарий в статье где говрится совсем о другом, то будте добры рассказать об этом подробно а не в общих чертах «это круто потому что оно во всем круто». Тогда и поговорить будет о чем. И инструмент популярнее станет.
А так ну может эта гибкость мне не нужна совсем. Ведь правда же у меня с SVN вообще нет проблем, и он удовлетворяет все мои потребности, особенно начиная с версии 1.5. Даже представить не могу зачем мне может понадобится что-то иное.
А так ну может эта гибкость мне не нужна совсем. Ведь правда же у меня с SVN вообще нет проблем, и он удовлетворяет все мои потребности, особенно начиная с версии 1.5. Даже представить не могу зачем мне может понадобится что-то иное.
кратко
Гит действительно сложная система. Если хочется сделать осознанный выбор, то придётся изучить его устройство, иначе все доводы превращаются в пустой звук.
Фундаментом Гита является устройство репозитория: а) DAG (можно считать, дерево) коммитов; б) криптографическая идентификация объектов; в) возможность создавать коммиты с более чем одним предком.
Всё остальное следует из этого, а именно:
1. Поддержка неограниченно сложной системы веток (и простая работа с частыми случаями типа «две ветки»).
2. Автоматический merge tracking. Реально когда понимаешь, что ДЕСЯТЬ ЛЕТ в Subversion не было этой фичи и когда понимаешь, насколько ЭЛЕМЕНТАРНО она сделана в Git — возникает глухая ярость за бесцельно потраченные годы :))
3. Полная функциональность локального репозитория. Вам не требуется быть постоянно подключенным к корпоративному репозиторию, и не нужно мучительно держать незакоммиченными тонны изменений только потому, что у вас нет подключения.
4. Возможно «переписать историю». Начиная от тривиального git commit --amend и заканчивая cherry-pick, позволяющий опубликовать изменения в вылизанном виде, сколь угодно отличающегося от длительной и мучительной разработки.
5. Распределенность, туды её в качель. Вообще, если пользователь Subversion говорит «зачем мне распределенность, я ею не пользуюсь» — это звучит как если пользователь Жигулей говорит «зачем мне ABS и подушка безопасности — я ими не пользуюсь». Конечно, не пользуешься, ведь у тебя их ПРОСТО НЕТУ :)))
В принципе нет ничего зазорного в том, что тошнить со скоростью 50 км/ч на своём жигулёнке. Важно только не удивляться, когда доедете, тому, насколько Вас обогнали, условно говоря, «конкуренты».
Гит действительно сложная система. Если хочется сделать осознанный выбор, то придётся изучить его устройство, иначе все доводы превращаются в пустой звук.
Фундаментом Гита является устройство репозитория: а) DAG (можно считать, дерево) коммитов; б) криптографическая идентификация объектов; в) возможность создавать коммиты с более чем одним предком.
Всё остальное следует из этого, а именно:
1. Поддержка неограниченно сложной системы веток (и простая работа с частыми случаями типа «две ветки»).
2. Автоматический merge tracking. Реально когда понимаешь, что ДЕСЯТЬ ЛЕТ в Subversion не было этой фичи и когда понимаешь, насколько ЭЛЕМЕНТАРНО она сделана в Git — возникает глухая ярость за бесцельно потраченные годы :))
3. Полная функциональность локального репозитория. Вам не требуется быть постоянно подключенным к корпоративному репозиторию, и не нужно мучительно держать незакоммиченными тонны изменений только потому, что у вас нет подключения.
4. Возможно «переписать историю». Начиная от тривиального git commit --amend и заканчивая cherry-pick, позволяющий опубликовать изменения в вылизанном виде, сколь угодно отличающегося от длительной и мучительной разработки.
5. Распределенность, туды её в качель. Вообще, если пользователь Subversion говорит «зачем мне распределенность, я ею не пользуюсь» — это звучит как если пользователь Жигулей говорит «зачем мне ABS и подушка безопасности — я ими не пользуюсь». Конечно, не пользуешься, ведь у тебя их ПРОСТО НЕТУ :)))
В принципе нет ничего зазорного в том, что тошнить со скоростью 50 км/ч на своём жигулёнке. Важно только не удивляться, когда доедете, тому, насколько Вас обогнали, условно говоря, «конкуренты».
Понятно. Мне оно пока не нужно, но когда понадобится, буду знать что оно есть. Хотя я пытался добиться все таки более развернутой статьи с примерами из жизни.
Насчет распределенности. Она есть. Но не в свн. Она просто есть. Как примсер Coda или OpenAFS
Насчет распределенности. Она есть. Но не в свн. Она просто есть. Как примсер Coda или OpenAFS
последний абзац я честно говоря не понял :)
я чего то не понял или гит умеет хранится более чем на одном сервере. обычно это понимается под словом «распределенный»
Ну, грубо говоря, в Git нет понятия «сервер» :-)
Чем это хорошо? А как оно работает? Кто то же должен следить за всеми рабочими копиями.
Тем, что сценариев работы теперь больше, чем один. Классический — один репозиторий считать центральным (сервер), а прочие — клиентскими копиями — всего лишь один из возможных вариантов. Годится, когда есть один продукт и мы его иногда выпускаем. Возможны же и иные случаи.
Вот пример — в Git-репозитории у меня хранятся мои персональные настройки (xmonad, vim, разные скрипты и т.д.). Есть репозиторий на рабочей машине, есть на домашней. Они в чём то должны отличаться — всё таки я пользуюсь не совсем одинаковым набором программ дома и на работе. Но большей частью они похожи, и я могу нужные мне изменения переливать из одного места в другое. В svn наверное, надо было заводить ветки.
Классический сценарий наиболее часто используемый я думаю (у меня не очень большой опыт Git-а). Он позволяет управлять доступом к репозиторию — скажем в master (это типа trunk) может лить только master manager или назовём его master master :) Те у кого нет доступа, могут слать патчи и т.д. Это, правда, можно сделать и в SVN, но разница здесь в том, что у тебя свой репозиторий, с которым ты можешь работать, подключаясь к центральному только для того, чтобы залить нужные изменения. Лёгкая работа с ветками этому очень помогает. За всеми рабочими копиями, разумеется, следить не надо.
В общем, мне описать очень трудно, просто попробуй.
Вот пример — в Git-репозитории у меня хранятся мои персональные настройки (xmonad, vim, разные скрипты и т.д.). Есть репозиторий на рабочей машине, есть на домашней. Они в чём то должны отличаться — всё таки я пользуюсь не совсем одинаковым набором программ дома и на работе. Но большей частью они похожи, и я могу нужные мне изменения переливать из одного места в другое. В svn наверное, надо было заводить ветки.
Классический сценарий наиболее часто используемый я думаю (у меня не очень большой опыт Git-а). Он позволяет управлять доступом к репозиторию — скажем в master (это типа trunk) может лить только master manager или назовём его master master :) Те у кого нет доступа, могут слать патчи и т.д. Это, правда, можно сделать и в SVN, но разница здесь в том, что у тебя свой репозиторий, с которым ты можешь работать, подключаясь к центральному только для того, чтобы залить нужные изменения. Лёгкая работа с ветками этому очень помогает. За всеми рабочими копиями, разумеется, следить не надо.
В общем, мне описать очень трудно, просто попробуй.
весь репозиторий есть у каждого разработчика. обмен ревизиями ведется командами pull (забрать изменения) и push (отправить изменения в другой репозиторий).
в крупных проектах обычно есть основной репозиторий, push'ить в который может ограниченный круг людей, они проводят code review изменений от других разработчиков и решают допускать их или нет в репозиторий.
в крупных проектах обычно есть основной репозиторий, push'ить в который может ограниченный круг людей, они проводят code review изменений от других разработчиков и решают допускать их или нет в репозиторий.
>push (отправить изменения в другой репозиторий).
В какой другой? Если я отправлю в репозиторий Васи, а не отправлю в репозиторий Пети. А если в команде 20 человек мне нужно всем отправить поочереди? А если я не хочу что бы мне кто то что-то отправлял?
В какой другой? Если я отправлю в репозиторий Васи, а не отправлю в репозиторий Пети. А если в команде 20 человек мне нужно всем отправить поочереди? А если я не хочу что бы мне кто то что-то отправлял?
в общий репозиторий отправлять нужно.
для начала можете рассматривать DVCS как эдакую продвинутую рабочую копию SVN, с возможность локального коммита.
пришел на работу с ноутбуком, поработал, покоммитил в общий репозиторий, пришел домой, придумал еще что-то, покоммитил в свой, пришел на работу, закоммитил домашнюю работу в общий репозиторий, ну здрово же, правда? =)
для начала можете рассматривать DVCS как эдакую продвинутую рабочую копию SVN, с возможность локального коммита.
пришел на работу с ноутбуком, поработал, покоммитил в общий репозиторий, пришел домой, придумал еще что-то, покоммитил в свой, пришел на работу, закоммитил домашнюю работу в общий репозиторий, ну здрово же, правда? =)
не
расскажите детально какой-нибудь случай из жизни!
расскажите детально какой-нибудь случай из жизни!
Я сам случай из жизни придумал. Правда я еще не рехнулся что бы в отпуске програмить, но бывают и такие люди.
Повторяю, не пытаюсь доказать что гит хуже свн. Лучше и намного, уже убедился. Я пытаюсь для себя понять стоит ли сейчас идти к одмину и просить его перевести репозиторий на гит, а потом доказывать программистам что они просто еще не осознали своего счастья
Повторяю, не пытаюсь доказать что гит хуже свн. Лучше и намного, уже убедился. Я пытаюсь для себя понять стоит ли сейчас идти к одмину и просить его перевести репозиторий на гит, а потом доказывать программистам что они просто еще не осознали своего счастья
тут можно только попоробовать
причем не обязательно отказываться от SVN есть www.kernel.org/pub/software/scm/git/docs/git-svn.html
и тогда SVN будет для Вас как еще один удаленый репозитарий.
Я сам так колебался, потом попробовал Hg, потом Git. Сейчас Git меня вполне устраивает. Хотя основной транк находится в SVN, для меня это просто еще одна ветка в Git.
причем не обязательно отказываться от SVN есть www.kernel.org/pub/software/scm/git/docs/git-svn.html
и тогда SVN будет для Вас как еще один удаленый репозитарий.
Я сам так колебался, потом попробовал Hg, потом Git. Сейчас Git меня вполне устраивает. Хотя основной транк находится в SVN, для меня это просто еще одна ветка в Git.
Кстати, было бы хорошо, если бы вы написали, как работается с git-svn. Насколько удобно «интегратору» сидеть на git «сбоку» от основного SVN (поддерживающего или нет merge tracking)?
А то я тут поработал с svk (работая с //local через рабочие копии svn клиента) и merge tracking — настолько всё было тяжело из-за того, что история мерджей в разных форматах и из-за того, что svk необратимо склеивает несколько разноплановых коммитов в один мердж-коммит. :(
А вот используя только git (есть опыт) всё так удобно и логично. Главное всегда помнить философию git — манипулирование не срезами деревьев в разные моменты (хотя эта фича тоже основная в git), а манипулирование патчами в контексте предыдущей истории проекта.
А то я тут поработал с svk (работая с //local через рабочие копии svn клиента) и merge tracking — настолько всё было тяжело из-за того, что история мерджей в разных форматах и из-за того, что svk необратимо склеивает несколько разноплановых коммитов в один мердж-коммит. :(
А вот используя только git (есть опыт) всё так удобно и логично. Главное всегда помнить философию git — манипулирование не срезами деревьев в разные моменты (хотя эта фича тоже основная в git), а манипулирование патчами в контексте предыдущей истории проекта.
я сейчас не использую svn-git (я как то побоялся его юзать, т.к. плохо знал устройство Git и как с ним работать)
сейчас использую одну ветку git как транк SVN куда подливаю все изменения.
когда надо закомитить в svn я просто грепаю лог git'а
и пишу что надо в комментарии к комиту
сейчас использую одну ветку git как транк SVN куда подливаю все изменения.
когда надо закомитить в svn я просто грепаю лог git'а
и пишу что надо в комментарии к комиту
Т.е. у вас есть master — стабильная общая ветка, а svn вы используете лишь в качестве источника для черрипикинга?
А куда зеркалятся svn-ветки с апстрима?
И есть ли какая-то автоматизация коммита в svn (я правильно понял, что вы просто через отдельную WC коммиттите?)?
А куда зеркалятся svn-ветки с апстрима?
И есть ли какая-то автоматизация коммита в svn (я правильно понял, что вы просто через отдельную WC коммиттите?)?
не совсем так.
ветки которые мне нужны есть в git c префиксом svn_
и я их полноценно мержу с всеми остальными (в которых работаю)
автоматизации нету (меня это сейчас мало смущает т.к. в один SVN коммит отправляется 2-3 фичи/ветки из GIT, и я понимаю что они делают)
именно для такой автоматизации создан svn-git, сейчас я бы стал его использовать.
Возможно и переду в ближайшее время.
ветки которые мне нужны есть в git c префиксом svn_
и я их полноценно мержу с всеми остальными (в которых работаю)
автоматизации нету (меня это сейчас мало смущает т.к. в один SVN коммит отправляется 2-3 фичи/ветки из GIT, и я понимаю что они делают)
именно для такой автоматизации создан svn-git, сейчас я бы стал его использовать.
Возможно и переду в ближайшее время.
удобно контролировать работу внештатников или каких-нибудь внешних разработчиков — они работают в своем репозитарии, выдавая коммиты на проверку разрабочикам проекта. При одобрении изменения помещаются в центральный репозаторий.
При этом:
а) Видна история коммитов внешних людей — видно кто/что/когда и зачем делал
б) Видно кто и когда поместил эти изменения в проект
в) Внешние разработчики могут легко перетягивать (merge'ить) к себе в рабочий репозитарий изменения в центральном хранилище, сохраняя актуальность своей копии проекта.
При этом:
а) Видна история коммитов внешних людей — видно кто/что/когда и зачем делал
б) Видно кто и когда поместил эти изменения в проект
в) Внешние разработчики могут легко перетягивать (merge'ить) к себе в рабочий репозитарий изменения в центральном хранилище, сохраняя актуальность своей копии проекта.
Здорово и правда. Только вот же блин, ну не работаю я дома и ноут с собой не таскаю. Дома нужно отдыхать. Впрочем дома у меня есть интернет и доступ в рабочий репозиторий. Хотя иногда может пригодится, не спорю. Например я был 2 недели в санатории где инета небыло. Мог бы кодить без проблем, а вернувшись в Москву закомитить.
в настроенный
вы же не просто так делаете push, а проектируете поток своих изменений
squadette.habrahabr.ru/blog/40462/
почитайте
вы же не просто так делаете push, а проектируете поток своих изменений
squadette.habrahabr.ru/blog/40462/
почитайте
это тупая файловая распределенность
а гитовская, обновляя рефы по своему протоколу — теснее ориентирована с самой идеей хранения истории изменений
а гитовская, обновляя рефы по своему протоколу — теснее ориентирована с самой идеей хранения истории изменений
какие ещё примеры из жизни Вам нужны? :)
Вам говорят «эта машина способна проехать тысячу километров на одном литре бензина». Вы говорите «расскажите подробнее пример из практики, как вы проехали 1000 километров на литре бензина».
что тут можно «рассказать»?
«Да, я тоже проехал 1000 километров и потратил 1 литр бензина», что ли?
по-моему, этот «рассказ» будет отдавать имбецильностью
Вам говорят «эта машина способна проехать тысячу километров на одном литре бензина». Вы говорите «расскажите подробнее пример из практики, как вы проехали 1000 километров на литре бензина».
что тут можно «рассказать»?
«Да, я тоже проехал 1000 километров и потратил 1 литр бензина», что ли?
по-моему, этот «рассказ» будет отдавать имбецильностью
Хочу уточнить по пункту 3. есть такой принцип: «Политика частых коммитов». Это договоренность о том что пользователи часто, как только это возможно без нарушения стабильности кода в транке, комитятся. Делается это для того что бы локальные копии программистов не расходились слишком далеко. Так вот всвязи с пунтом 3 не получится ли так, что программеры будут комитить все на сервер только по большим церковным праздникам?
это уже вопрос политики компании
никто не мешает в Subversion коммитить один раз в неделю с комментарием «Уфф, пятница» :)
никто не мешает в Subversion коммитить один раз в неделю с комментарием «Уфф, пятница» :)
вот как всё-таки можно так путать логические уровни, блин :)
«будет, потому что может», и «не будет, потому что иначе не может» — какая пропасть в мировоззрении есть между этими вещами
«будет, потому что может», и «не будет, потому что иначе не может» — какая пропасть в мировоззрении есть между этими вещами
Пропасть не в нашем мировоззрении, а мировоззрении быдлокодеров которым не вдолбишь что коммититься нужно часто. Если у них будет возможность не коммитится они и не будут пока не пнешь.
Это относится и к написанию тестов. Они понимают что тесты имеют массу преимуществ. Но тут же надо мозгом шевелить.
Так же между прочим и отношении к веткам. Все программисты в офисе в лучшем случае об этом только слышали краем уха. Прошу их уже неделю прочесть свнбук по веткам. Отгадайте с трех раз хотя бы один прочел?
Это относится и к написанию тестов. Они понимают что тесты имеют массу преимуществ. Но тут же надо мозгом шевелить.
Так же между прочим и отношении к веткам. Все программисты в офисе в лучшем случае об этом только слышали краем уха. Прошу их уже неделю прочесть свнбук по веткам. Отгадайте с трех раз хотя бы один прочел?
«Даже представить не могу зачем мне может понадобится что-то иное.»
А как Вы работаете с SVN
— сколько коммитов Вы делаете в день?
— сколько бранчей обычно в репозитарии?
— сколько разработчиков в проекте?
если ответы на все эти вопросы < 5, то SVN вам вроде должно хватать.
а если нет, то готов рассказать что станет в Вашей жизни лучше если Вы перейдете на Git
А как Вы работаете с SVN
— сколько коммитов Вы делаете в день?
— сколько бранчей обычно в репозитарии?
— сколько разработчиков в проекте?
если ответы на все эти вопросы < 5, то SVN вам вроде должно хватать.
а если нет, то готов рассказать что станет в Вашей жизни лучше если Вы перейдете на Git
Вообще допустим вам предлагают скажем форд и ферари. Что вы выберете? Конечно же ферари! Кто бы сомневался. Но допустим что машина вам нужна для того что бы развозить посылки и письма от одного дома к другому. Разогнаться не успеваешь как уже тормозить. Это можно делать и на той машине и на той, но вот в этом случае пофигу на то что феррари более мощная. Для вашей задачи эта мощь не нужна, её негде использовать. Но у феррари есть одно преимущество. Развозить почту на феррари это круто. Так же как пользоваться Git вместо svn в большеносые задач :)))
great minds think alike
именно автомобильную метафору я и использовал
именно автомобильную метафору я и использовал
я нанимаю кучу разработчиков, и однажды у меня был показательный момент в собеседовании
я задавал человека обычный набор вопросов по (простейшим) структурам данных. хэши да деревья, совершенно ничего из ряда вон выходящего.
человек же был программистом на пыхопэ, писал какие-то говносайты, и в какой-то момент заявил мне: «зачем вообще нужны эти структуры данных, мне вот они ни разу не потребовались за всю мою карьеру.»
«ну как же», говорю я — «представьте себе, что вам придётся писать какую-нибудь реально сложную систему, например систему распознавания движущихся объектов с видеозаписи. куда там без структур данных, к тому же гораздо более сложных.»
«ну мне пока что системы видео-распознавания писать не доводилось, а когда понадобится — выучу», гордо заметил товарищ.
я уж как мог постарался до него донести, что это не ему не просто «не доводилось», а на самом деле про него и подумают-то в последнюю очередь, потому что он самостоятельно и превентивно не удосужился изучить основы computer science.
то есть подход «так как я не участвую в формуле-1, то езжу на жигулях, а как меня пригласят в команду — так я сразу подкачаю скиллы-то» — он приводит к тому, что ни в какую формулу-1 Вас не пригласят
потому что сначала скиллы
а потом уже предложение
но в принципе конечно ничего зазорного в том, чтобы не участвовать в формуле-1 — нету :)))
я задавал человека обычный набор вопросов по (простейшим) структурам данных. хэши да деревья, совершенно ничего из ряда вон выходящего.
человек же был программистом на пыхопэ, писал какие-то говносайты, и в какой-то момент заявил мне: «зачем вообще нужны эти структуры данных, мне вот они ни разу не потребовались за всю мою карьеру.»
«ну как же», говорю я — «представьте себе, что вам придётся писать какую-нибудь реально сложную систему, например систему распознавания движущихся объектов с видеозаписи. куда там без структур данных, к тому же гораздо более сложных.»
«ну мне пока что системы видео-распознавания писать не доводилось, а когда понадобится — выучу», гордо заметил товарищ.
я уж как мог постарался до него донести, что это не ему не просто «не доводилось», а на самом деле про него и подумают-то в последнюю очередь, потому что он самостоятельно и превентивно не удосужился изучить основы computer science.
то есть подход «так как я не участвую в формуле-1, то езжу на жигулях, а как меня пригласят в команду — так я сразу подкачаю скиллы-то» — он приводит к тому, что ни в какую формулу-1 Вас не пригласят
потому что сначала скиллы
а потом уже предложение
но в принципе конечно ничего зазорного в том, чтобы не участвовать в формуле-1 — нету :)))
Ага, все такие умные на собеседовании, спрашивают про структуры данных и т.д.
А если прошел таки собеседование, делаешь все те же говносайты на пэхэпэ.
Вот когда вы напишете, что-то лучше пэхэпэ, тогда и сможете так небрежно о нем отзываться.
А узнать сообразительный парень или нет, можно узнать и не спрашивая основы.
Основы можно выучить, все можно выучить, но если человек дурак то ему основы не помогут.
А если прошел таки собеседование, делаешь все те же говносайты на пэхэпэ.
Вот когда вы напишете, что-то лучше пэхэпэ, тогда и сможете так небрежно о нем отзываться.
А узнать сообразительный парень или нет, можно узнать и не спрашивая основы.
Основы можно выучить, все можно выучить, но если человек дурак то ему основы не помогут.
«ну или так» (а)
молодец, прошёлся по всем комментом с минусом ;)
«сообразительный парень»!
P.S.: карму минуснуть забыл!
молодец, прошёлся по всем комментом с минусом ;)
«сообразительный парень»!
P.S.: карму минуснуть забыл!
Оба права. Не надо засталять себя знать основы. Нужно просто стремиться к самообразованию, а все эти знания тогда как бы прилагаются. И не важно на каком языке програмишь. Я вот тоже лучше всего знаю PHP. Но это не мешает мне сейчас писать на Java, и интересоватся тем что вообще выходит за пределы конкретного языка. XP, TDD, Паттерны проектирования, Linux и тд.
Заставляют другие. Причем обиднее всего когда хотят показать своими знаниями свое превосходство, мол вот я какой образованный, а это тут программист на «пыхопэ, писал какие-то говносайты».
Бывают конечно те еще кадры устраиваются на работу, прочитав книгу Котерева и хотят получать 40 тыс. руб. в месяц.
Бывают конечно те еще кадры устраиваются на работу, прочитав книгу Котерева и хотят получать 40 тыс. руб. в месяц.
намного хуже когда у человека 10 лет опыта за плечами и все основы он знает, но чуть глубже копни, чуть в сторону и все. и спрашивается ты что все 10 лет только свой язык учил? неужели больше совсем ничего не интересно?.. вот это уже клиника. человека, считающего себя гуру уже не заставишь учиться. Если молодой чего-то не знает — может не успел. Но если не знает опытный, то скорее всего просто не захотел это знать.
прямо про вас написано, с поразительным упорством на все аргументы про преимущества распределенных VCS вы отвечаете «ну и че?».
Неа. Я задаю наводящие вопросы))) Я понимаю что сейчас меня на 100% устраивает SVN, и даже если гит настолько крут, все мои потребности удовлетворяет SVN. Но хочу знать о GIT больше. Кое какую документацию уже почитал, но гораздо интереснее спросить у знающих опытных людей. Например распределенный. Я нашел что фича такая есть а вот нафига она в реальных проектах, я так и не понял. Такое чувство, что это просто побочный эффект или аттавизм времен когда инет был дорогой… Вот я и пытаюсь разобраться. А было бы мне неинтересно, я бы сказал «Не нужно мне это» и забыл бы о GIT благополучно. А я наоборот стараюсь найти причины почему мне это нужно.
Мало того, я уже принял решение что один из моих собственных проектов я переведу на GIT. Недельки через две будет время.
Мало того, я уже принял решение что один из моих собственных проектов я переведу на GIT. Недельки через две будет время.
я вот тоже как-то стеснялся сказать, что в общем интерес к дискуссии теряю достаточно быстро
ну ничего, я верю в хабр
акиры не подведут
ну ничего, я верю в хабр
акиры не подведут
Вы путаете логические уровни, кстати
«Я не использую» и «я не знаю».
я тоже на нескольких проектах использую Subversion, и в ближайшее время переходить не собираюсь (хотя кстати всегда можно прицепить рядом git svn, и никто
ничего
не заметит даже :))
«Я не использую» и «я не знаю».
я тоже на нескольких проектах использую Subversion, и в ближайшее время переходить не собираюсь (хотя кстати всегда можно прицепить рядом git svn, и никто
ничего
не заметит даже :))
Можно подробнее про git svn?
И как вообще проще переехать с svn на git с сохранением истории (если это реально), и есть ли аналогичные утилиты типа черепахи?
И как вообще проще переехать с svn на git с сохранением истории (если это реально), и есть ли аналогичные утилиты типа черепахи?
это не просто реально, а если полноценный и бескомпромиссный двунаправленный гейтвей между Subversion и Git
входит непосредственно в дистрибутив и называется «git svn» :)
то есть
вы можете склонировать полную (или часть) историю изменений svn-репозитория и превратить её в гитовый репо.
соответственно возникнет двунаправленная связь между ветками в svn и ветками в этом git-репо
дальше можно а) свободно работать в гит-репо без ограничений. затем внесенные изменения на ветке закоммитить обратно в Subversion.
б) обновлять (инкрементально) содержимое гит-репо, доимпортируя новые коммиты из svn-репо. при этом внутри гита будет обычный merge-tracking, который позволит эти svn-коммиты безболезненно накатить.
то есть теоретически ваши коллеги могут не подозревать, что вы не пользуетесь Subversion :)
я это наблюдал непосредственно в продакшене
входит непосредственно в дистрибутив и называется «git svn» :)
то есть
вы можете склонировать полную (или часть) историю изменений svn-репозитория и превратить её в гитовый репо.
соответственно возникнет двунаправленная связь между ветками в svn и ветками в этом git-репо
дальше можно а) свободно работать в гит-репо без ограничений. затем внесенные изменения на ветке закоммитить обратно в Subversion.
б) обновлять (инкрементально) содержимое гит-репо, доимпортируя новые коммиты из svn-репо. при этом внутри гита будет обычный merge-tracking, который позволит эти svn-коммиты безболезненно накатить.
то есть теоретически ваши коллеги могут не подозревать, что вы не пользуетесь Subversion :)
я это наблюдал непосредственно в продакшене
к сожалению, Тортвайза нету :(
но можно засетапить так, что дизайнеры сидят под svn/tortoisesvn, а девелоперы пользуются гитом
я думаю, что рано или поздно мы у себя так и сделаем
но можно засетапить так, что дизайнеры сидят под svn/tortoisesvn, а девелоперы пользуются гитом
я думаю, что рано или поздно мы у себя так и сделаем
Она в моём списке TODO сразу же после статьи «Запорожец vs лендровер».
Ну правда, расскажите — чем круче?
Может быть тем, что они являются распределенной системой?
Может быть, только возникает вопрос, а если эта фича не требуется?
«Распределенность» Гита — это лишь побочный эффект его невероятной концептуальной мощности :)
У меня возникает уже ощущение что поклоники гита не понимают чем он лучше SVN, поэтому просто говорят заученными фразами из документации.
OLOLO
товарищ
я подозреваю, что приблизительно четверть программистов на постсоветской территории начали пользоваться системами контроля версий так или иначе на основании моих трудов на эту тему.
ever heard of alexm.here.ru/cvs-ru/
? :)
товарищ
я подозреваю, что приблизительно четверть программистов на постсоветской территории начали пользоваться системами контроля версий так или иначе на основании моих трудов на эту тему.
ever heard of alexm.here.ru/cvs-ru/
? :)
промт тоже в состоянии перевести документацию по cvs
:)
Вы чего сказать-то хотите? :)
теоретически я должен чувствовать сострадание и уважение ко всем живым существам
но я, знаете, человек слабый
и поэтому мне сложно всерьёз воспринимать людей со столь чётким лейблом «Pioneriis Vacuumcephali» на лбу :)
постарайтесь написать другой комментарии, более умный :)
а этот сотрите, не позорьтесь :)
Вы чего сказать-то хотите? :)
теоретически я должен чувствовать сострадание и уважение ко всем живым существам
но я, знаете, человек слабый
и поэтому мне сложно всерьёз воспринимать людей со столь чётким лейблом «Pioneriis Vacuumcephali» на лбу :)
постарайтесь написать другой комментарии, более умный :)
а этот сотрите, не позорьтесь :)
забыл тег irony, думал и так поймёте
вам — безусловно респект за доступ к репозиториям cvs/svn, но если вы хотели потрясти своим длинным экспериенсом — нужно было с этого и начинать, а то перевод документации выглядит слабенько… :-)
вам — безусловно респект за доступ к репозиториям cvs/svn, но если вы хотели потрясти своим длинным экспериенсом — нужно было с этого и начинать, а то перевод документации выглядит слабенько… :-)
ну, слабенько — не слабенько, а официальной документацией в русском Интеле этот перевод был
так что ша, дружок
как там Предводитель Акира говорит — когда напишешь лучше — заходи
так что ша, дружок
как там Предводитель Акира говорит — когда напишешь лучше — заходи
ну, слабенько — не слабенько, а официальной документацией в русском Интеле этот перевод был
так что ша, дружок
как там Предводитель Акира говорит — когда напишешь лучше — заходи
так что ша, дружок
как там Предводитель Акира говорит — когда напишешь лучше — заходи
ничего, что у меня был commit-доступ в дерево исходников CVS и пара (простых, правда) коммитов, принятых в Subversion? :)
тем что с помощью Git / Hg я могу сделать ВСЕ что может SVN, а вот наоблорот не получится :)
люди собственно и просят жизненных примеров :-)
Да? Предложите тогда решение для следующих use case:
1) Файл/каталог B _внутри_ репозитория создан с помощью чего-то вроде svn copy на основе, соответственно, файла/каталога A. Есть ли способ из такого подпроекта B черрипикнуть изменения в подпроект A с помощью git? Как в таком случае (раздвоения части проекта на несколько) поступают git`овцы? Неужели сразу, как только забрезжит такая возможность, выкидывают кусок изменений в субмодули (та ещё нетривиальная задача, поскольку, как минимум, все теги в субмодуле исчезнут/станут кривыми)?
/* По мне, так неподдерживание git`ом равноправных вложенных деревьев — самый большой его недостаток. С другой, стороны, понятно, для чего так сделано: ясность и производительность. */
2) Как с помощью git работать над драйвером linux из дистрибутива ядра так, что бы не тащить к себе в раздел всё дерево исходников linux в качестве working copy?
1) Файл/каталог B _внутри_ репозитория создан с помощью чего-то вроде svn copy на основе, соответственно, файла/каталога A. Есть ли способ из такого подпроекта B черрипикнуть изменения в подпроект A с помощью git? Как в таком случае (раздвоения части проекта на несколько) поступают git`овцы? Неужели сразу, как только забрезжит такая возможность, выкидывают кусок изменений в субмодули (та ещё нетривиальная задача, поскольку, как минимум, все теги в субмодуле исчезнут/станут кривыми)?
/* По мне, так неподдерживание git`ом равноправных вложенных деревьев — самый большой его недостаток. С другой, стороны, понятно, для чего так сделано: ясность и производительность. */
2) Как с помощью git работать над драйвером linux из дистрибутива ядра так, что бы не тащить к себе в раздел всё дерево исходников linux в качестве working copy?
я согласен про этот недостаток
1) каждый проект — свой репозитарий
так что приходится выкидывать в суб-модули
про теги в суб-модуле, не знаю не юзал
2) никак, т.к. идеология git — работать со всем проектом, а не с файлами/директориями
и проект ведется соответственно этой идеологии, что учит нас разрабатывать не кусочки, а законченные решения.
1) каждый проект — свой репозитарий
так что приходится выкидывать в суб-модули
про теги в суб-модуле, не знаю не юзал
2) никак, т.к. идеология git — работать со всем проектом, а не с файлами/директориями
и проект ведется соответственно этой идеологии, что учит нас разрабатывать не кусочки, а законченные решения.
1) и реально выкидываются (случаи, когда подпроект существует уже несколько месяцев не в счёт), или это вы предположили из общих соображений?
про теги имелось в виду — то, что при любой переписи истории, криптографические теги будут испорчены, поскольку они созданы для другого коммита/дерева.
2) получается, не всё, что может SVN. Он хорош именно проработанностью в смысле use cases (с учётом, что когда SVN проектировался, мерджи и DVCS-фичи редко какие проекты использовали). То, что исполнителю можно дать определённый небольшой участочек работы — это очень удобно.
Понятно, что с этими ограничениями борются планированием структуры проекта, но SVN удобен тем, что можно именно разрабатывать активно (впрочем, в других аспектах git рулит в этом отношении ещё больше).
про теги имелось в виду — то, что при любой переписи истории, криптографические теги будут испорчены, поскольку они созданы для другого коммита/дерева.
2) получается, не всё, что может SVN. Он хорош именно проработанностью в смысле use cases (с учётом, что когда SVN проектировался, мерджи и DVCS-фичи редко какие проекты использовали). То, что исполнителю можно дать определённый небольшой участочек работы — это очень удобно.
Понятно, что с этими ограничениями борются планированием структуры проекта, но SVN удобен тем, что можно именно разрабатывать активно (впрочем, в других аспектах git рулит в этом отношении ещё больше).
я не верю в «участочек работы» в рамках большого проекта, в отрыве от всего проекта.
Это любо два разных проекта, либо один.
У нас в репозитарии 4 экстернела, 2 из них реально отдельные проекты, и они лежать отдельно. И от их иногда «неудачных» обновлений страдают лишь они сами. И поэтому у них отдельные репозитарии.
2 других фактически часть нашего проекта, которую вынесли для разработки «ВНЕ» (участочки работы, блин), и это два нам постоянно все ломают. И если бы разработчики этих двух проектов, работали со всей системой «в целом» такого бы не было.
Это любо два разных проекта, либо один.
У нас в репозитарии 4 экстернела, 2 из них реально отдельные проекты, и они лежать отдельно. И от их иногда «неудачных» обновлений страдают лишь они сами. И поэтому у них отдельные репозитарии.
2 других фактически часть нашего проекта, которую вынесли для разработки «ВНЕ» (участочки работы, блин), и это два нам постоянно все ломают. И если бы разработчики этих двух проектов, работали со всей системой «в целом» такого бы не было.
Кажется пошли темы уже не зависимые от сабжа. Организация разработки большая, интересная тема. Это отдельный блог, не видел есть ли он на хабре, но мысли по этому поводу у меня есть и статью хочу написать. Но после 1 декабря.
Вообще-то, прямо зависимые. Одно дело рассматривать сферические мерджи в вакууме (что SVN, что git с такими _не_ справляются — то контекста им не хватает, то ещё чего), другое — реальные ситуации правки исходников и бинарников конкретного проекта.
Пример с драйверами в Linux показательный, т.к. драйвера, поддерживающие модульное исполнение, как правило, — независимое от основного ядра ПО, размещённое в отдельном каталоге. В svn для их форка достаточно просто сделать svn copy, а в git для этого придётся переписывать историю коммитов, с выкидыванием из changeset`ов не относящихся к данному драйверу файлов. При этом история изменений в случае SVN сохранится в виде «бесплатного» приложения к копированию, а в случае git придётся следить за копированиями, склейками и переименованиями файлов вручную (можно скрипт написать, но пока общеупотребимого нет). Поэтому, несмотря на централизованность, SVN, я считаю, остаётся более динамичным в плане разработки, естественно, в случае, когда распределённости не требуется впрямую (<20 разработчиков из одной конторы над одним [под]проектом). Но вот дикая сложность мерджей угнетает, особенно, когда апстрим работает под версией <1.5.
Опять же, описанные ситуации довольно редкие и относятся больше к скриптовым, а не транслируемым в машинный код проектами. Так что, опять же специфика предмета проекта влияет на выбор «правильной» VCS/SCM.
Кстати, вроде бы в Mercurial с расширением forest, указанная проблема решается.
Пример с драйверами в Linux показательный, т.к. драйвера, поддерживающие модульное исполнение, как правило, — независимое от основного ядра ПО, размещённое в отдельном каталоге. В svn для их форка достаточно просто сделать svn copy, а в git для этого придётся переписывать историю коммитов, с выкидыванием из changeset`ов не относящихся к данному драйверу файлов. При этом история изменений в случае SVN сохранится в виде «бесплатного» приложения к копированию, а в случае git придётся следить за копированиями, склейками и переименованиями файлов вручную (можно скрипт написать, но пока общеупотребимого нет). Поэтому, несмотря на централизованность, SVN, я считаю, остаётся более динамичным в плане разработки, естественно, в случае, когда распределённости не требуется впрямую (<20 разработчиков из одной конторы над одним [под]проектом). Но вот дикая сложность мерджей угнетает, особенно, когда апстрим работает под версией <1.5.
Опять же, описанные ситуации довольно редкие и относятся больше к скриптовым, а не транслируемым в машинный код проектами. Так что, опять же специфика предмета проекта влияет на выбор «правильной» VCS/SCM.
Кстати, вроде бы в Mercurial с расширением forest, указанная проблема решается.
Мне понравилась идея работы без центрального сервера. И отсутствие метаданных типа .svn в каталогах проекта.
Что значит понравилась идея… чем понравилась?
Отсутствие мусора это +. Не существенно, но все таки некоторый геморрой убирает.
Отсутствие мусора это +. Не существенно, но все таки некоторый геморрой убирает.
Уфф, уже жалею о своём первом посте здесь, вы меня как пытаете :) Ладно, придётся отвечать за необдуманные посты. У меня однажды появилась такая проблема rsdn.ru/Forum/message/2918815.flat.aspx#2918815 — и мне прекрасно подошло решение, методом замены subversion на mercurial
По моему для этого существуют ветки.
Мне там и советовали их использовать… но мне кажется это не очень логичным для временных данных. Да и соединение с интернет не всегда есть, либо медленное.
P.S. Уфф, извиняюсь за свой пост, но кажется из-за меня тут холивар собирается :)
P.S. Уфф, извиняюсь за свой пост, но кажется из-за меня тут холивар собирается :)
По теме. Ведь статья про ветки.
Так вот кажется не кажется а ветки именно для этого и существуют. Там советовали правильно. Переходить на другую систему только из за того что ветки показались чем то страшным наверное решение принятое с горяча. Нельзя так панически боятся нового. Наоборот наверное новое должно привлекать пытливые умы программистов)))
Так вот кажется не кажется а ветки именно для этого и существуют. Там советовали правильно. Переходить на другую систему только из за того что ветки показались чем то страшным наверное решение принятое с горяча. Нельзя так панически боятся нового. Наоборот наверное новое должно привлекать пытливые умы программистов)))
а метаданные типа .git? ;-)
зависит от того что тебе нужно.
если ты просто привык коммитить уже сделанные вещи, и ты успеваешь сделать итерацию за день то ничем.
я использую иначе:
— каждая фича — свой бранч
— каждое законченное изменение (функция, шаблон, правило) — коммит (в среднем я комичу раз в 10 минут)
— в работе 5-10 фичей одновременно, причем я могу переключится с одной на другую за пару секунд
— в транк попадают только законченые и протестированые фичи (тестирование и транк на др. хостах), тут отлично применяется распределенность
причем GIT сам навязывает такой стиль разработки
можно ли все это также просто и легко сделать в SVN???
а если в проекте 5-10 человек?
ЗЫ
ну и специально для тебя, в TM есть отличный GIT.bundle, благодаря которому можно не вникать в устройство GIT'а, а просто его использовать :)
если ты просто привык коммитить уже сделанные вещи, и ты успеваешь сделать итерацию за день то ничем.
я использую иначе:
— каждая фича — свой бранч
— каждое законченное изменение (функция, шаблон, правило) — коммит (в среднем я комичу раз в 10 минут)
— в работе 5-10 фичей одновременно, причем я могу переключится с одной на другую за пару секунд
— в транк попадают только законченые и протестированые фичи (тестирование и транк на др. хостах), тут отлично применяется распределенность
причем GIT сам навязывает такой стиль разработки
можно ли все это также просто и легко сделать в SVN???
а если в проекте 5-10 человек?
ЗЫ
ну и специально для тебя, в TM есть отличный GIT.bundle, благодаря которому можно не вникать в устройство GIT'а, а просто его использовать :)
О. А вот это ответ ) Спасибо!
Спасибо.
Теперь более или мение представляю себе чем меня может GIT захватить. Изменением стиля разработки. Ведь с ветками SVN создавать ветки на каждый чих накладно, поэтому часть кода правится в транке. Но ясно же что это компромисс.
Теперь более или мение представляю себе чем меня может GIT захватить. Изменением стиля разработки. Ведь с ветками SVN создавать ветки на каждый чих накладно, поэтому часть кода правится в транке. Но ясно же что это компромисс.
svnmerge.py больше не нужен?
да, если не боитесь ставить в продакшен 1.5
это не FUD, я лично просто нервничаю от этой идеи
мне для полного счастья ещё риска выгребания проблем от апгрейда не хватает
тошним на svnmerge :))
это не FUD, я лично просто нервничаю от этой идеи
мне для полного счастья ещё риска выгребания проблем от апгрейда не хватает
тошним на svnmerge :))
Подозреваю, что должна быть какая-то процедура для переезда с истории ревизий, изнасилованной svnmerge, на валидную историю svn 1.5, без этого вряд ли кто-то рискнёт мигрировать. А если с нуля начинать, то вполне нормально, subversion всегда был довольно стабилен, грабли обычно расставлены на точках входа (производительность, например, на разных протоколах).
Сегодня наш одмин проабгрейдил все минут за 15. Ни одной проблемы. Все работает как и раньше только новые фичи появились.
ну и охренеть можно
а как насчёт tags
просто перед merge
тянешь tag, называешь
как удобно и будет вам
счастие
а как насчёт tags
просто перед merge
тянешь tag, называешь
как удобно и будет вам
счастие
Простое правило: -тся пишется, когда имеет место вопрос «что делает?»; -ться — когда «что делать?»
Ах, наш админ никак не обновит svn-клиент на серваке (на котором мы разрабатываем) до 1.5, ибо под debian никак stable не выйдет…
в статье не хватает начальных условий. очень было бы хорошо, если бы для всех команд, модифицирующих сорсы, были приведены:
1. текущая директория
2. куда в действительности эта директория смотрит (куда был сделан свитч)
1. текущая директория
2. куда в действительности эта директория смотрит (куда был сделан свитч)
Это же продолжение этой статьи
Пасиба! Как раз сейчас работаю с svn и ветками:)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Работа с ветками в SVN. Изменения в версии 1.5.