Продолжение
этой статьи
Долгое время в ветках SVN был один существенный недостаток. Система не помнила мержей, и программисту приходилось самостоятельно заботиться о том, что бы сохранить номер ревизии, когда происходило копирование изменений из транка. Проблема частично решалась добавлением комментариев в лог, но все таки это было чревато ошибками, и целиком ложилось на совесть программиста.
В версии 1.5, наконец-то, программисты Subversion выполнили свое давнее обещание, и добавили несколько полезных фич для работы с ветками.
Итак, в версии 1.5 команда merge обзавелась двумя новыми опциями:
--record-only и
--reintegrate.
Теперь ответственность за контроль копирования изменений ложится целиком на плечи SVN (merge tracking), а программист может легко, и без боязни выполнять merge так часто, словно это команда update.
Теперь совершенно не нужно заботится о сохранении номера ревизии последнего мержа. SVN поумнел настолько, что сам копирует только те изменения, которых у вас еще нет. Если раньше вам приходилось указывать диапазон ревизий с помощью ключа -r то теперь достаточно просто выполнить команду
#svn merge svn://svnserver/var/bump/trunk
И SVN сам все поймет:
--- Merging r154 through r155 into '.':
U app/view/blogs/view.tpl.html
Второе полезное изменение связано с копированием ваших изменений в транк. И снова SVN великодушно заботится о нас, и сам копирует только те изменения, которых нет в транке.
svn merge --reintegrate svn://svnserver/var/bump/branches/my-branch
Эта команда объединит вашу ветку с транком. Снова никаких лишних движений, все очень просто.
Опция
--record-only используется для того что бы пометить диапазон ревизий, как слитые. То есть в следующий раз svn не будет пытаться скопировать изменения из этих ревизий в вашу ветку.
#svn merge -r155:157 --record-only svn://svnserver/var/bump/trunk
Теперь все изменения из диапазона ревизий 155:157 будут проигнорированы.
Появилась допонительная опция у комманд svn log и svn blame
svn log --use-merge-history --limit 3
------------------------------------------------------------------------
r155 | rvk | 2008-11-24 15:22:04 +0300 (Пнд, 24 Ноя 2008) | 1 line
Merged via: r156
fixed small bug
------------------------------------------------------------------------
r154 | rvk | 2008-11-24 14:15:29 +0300 (Пнд, 24 Ноя 2008) | 1 line
new branch named new_design
------------------------------------------------------------------------
И еще одна полезная опция svn mergeinfo, с помощью которой можно посмотреть какие ревизии уже смержены:
#svn mergeinfo svn://svnserver/var/bump/trunk
Или какие изменения еще могут быть скопированы из транка:
#svn mergeinfo svn://svnserver/var/bump/trunk --show-revs eligible
Как всегда, подробнее, можно прочесть в
svnbook
комментарии (123)
Русский перевод. Неполный и устаревший, так что учите английский.
то есть если Вам один человек некомпетентно что-то рассказал — Вы не будете пользоваться существенно более мощным решением? :)
это в принципе даже хорошо, меньше конкуренции
если серьезно, то Git с концептуальной точки зрения делает Subversion на всех возможных уровнях.
на Svn есть очень чёткий потолок сложности
в Git его нету :)
А так ну может эта гибкость мне не нужна совсем. Ведь правда же у меня с SVN вообще нет проблем, и он удовлетворяет все мои потребности, особенно начиная с версии 1.5. Даже представить не могу зачем мне может понадобится что-то иное.
Гит действительно сложная система. Если хочется сделать осознанный выбор, то придётся изучить его устройство, иначе все доводы превращаются в пустой звук.
Фундаментом Гита является устройство репозитория: а) DAG (можно считать, дерево) коммитов; б) криптографическая идентификация объектов; в) возможность создавать коммиты с более чем одним предком.
Всё остальное следует из этого, а именно:
1. Поддержка неограниченно сложной системы веток (и простая работа с частыми случаями типа «две ветки»).
2. Автоматический merge tracking. Реально когда понимаешь, что ДЕСЯТЬ ЛЕТ в Subversion не было этой фичи и когда понимаешь, насколько ЭЛЕМЕНТАРНО она сделана в Git — возникает глухая ярость за бесцельно потраченные годы :))
3. Полная функциональность локального репозитория. Вам не требуется быть постоянно подключенным к корпоративному репозиторию, и не нужно мучительно держать незакоммиченными тонны изменений только потому, что у вас нет подключения.
4. Возможно «переписать историю». Начиная от тривиального git commit --amend и заканчивая cherry-pick, позволяющий опубликовать изменения в вылизанном виде, сколь угодно отличающегося от длительной и мучительной разработки.
5. Распределенность, туды её в качель. Вообще, если пользователь Subversion говорит «зачем мне распределенность, я ею не пользуюсь» — это звучит как если пользователь Жигулей говорит «зачем мне ABS и подушка безопасности — я ими не пользуюсь». Конечно, не пользуешься, ведь у тебя их ПРОСТО НЕТУ :)))
В принципе нет ничего зазорного в том, что тошнить со скоростью 50 км/ч на своём жигулёнке. Важно только не удивляться, когда доедете, тому, насколько Вас обогнали, условно говоря, «конкуренты».
Насчет распределенности. Она есть. Но не в свн. Она просто есть. Как примсер Coda или OpenAFS
Вот пример — в Git-репозитории у меня хранятся мои персональные настройки (xmonad, vim, разные скрипты и т.д.). Есть репозиторий на рабочей машине, есть на домашней. Они в чём то должны отличаться — всё таки я пользуюсь не совсем одинаковым набором программ дома и на работе. Но большей частью они похожи, и я могу нужные мне изменения переливать из одного места в другое. В svn наверное, надо было заводить ветки.
Классический сценарий наиболее часто используемый я думаю (у меня не очень большой опыт Git-а). Он позволяет управлять доступом к репозиторию — скажем в master (это типа trunk) может лить только master manager или назовём его master master :) Те у кого нет доступа, могут слать патчи и т.д. Это, правда, можно сделать и в SVN, но разница здесь в том, что у тебя свой репозиторий, с которым ты можешь работать, подключаясь к центральному только для того, чтобы залить нужные изменения. Лёгкая работа с ветками этому очень помогает. За всеми рабочими копиями, разумеется, следить не надо.
В общем, мне описать очень трудно, просто попробуй.
в крупных проектах обычно есть основной репозиторий, push'ить в который может ограниченный круг людей, они проводят code review изменений от других разработчиков и решают допускать их или нет в репозиторий.
В какой другой? Если я отправлю в репозиторий Васи, а не отправлю в репозиторий Пети. А если в команде 20 человек мне нужно всем отправить поочереди? А если я не хочу что бы мне кто то что-то отправлял?
для начала можете рассматривать DVCS как эдакую продвинутую рабочую копию SVN, с возможность локального коммита.
пришел на работу с ноутбуком, поработал, покоммитил в общий репозиторий, пришел домой, придумал еще что-то, покоммитил в свой, пришел на работу, закоммитил домашнюю работу в общий репозиторий, ну здрово же, правда? =)
расскажите детально какой-нибудь случай из жизни!
Повторяю, не пытаюсь доказать что гит хуже свн. Лучше и намного, уже убедился. Я пытаюсь для себя понять стоит ли сейчас идти к одмину и просить его перевести репозиторий на гит, а потом доказывать программистам что они просто еще не осознали своего счастья
причем не обязательно отказываться от SVN есть www.kernel.org/pub/software/scm/git/docs/git-svn.html
и тогда SVN будет для Вас как еще один удаленый репозитарий.
Я сам так колебался, потом попробовал Hg, потом Git. Сейчас Git меня вполне устраивает. Хотя основной транк находится в SVN, для меня это просто еще одна ветка в Git.
А то я тут поработал с svk (работая с //local через рабочие копии svn клиента) и merge tracking — настолько всё было тяжело из-за того, что история мерджей в разных форматах и из-за того, что svk необратимо склеивает несколько разноплановых коммитов в один мердж-коммит. :(
А вот используя только git (есть опыт) всё так удобно и логично. Главное всегда помнить философию git — манипулирование не срезами деревьев в разные моменты (хотя эта фича тоже основная в git), а манипулирование патчами в контексте предыдущей истории проекта.
сейчас использую одну ветку git как транк SVN куда подливаю все изменения.
когда надо закомитить в svn я просто грепаю лог git'а
и пишу что надо в комментарии к комиту
А куда зеркалятся svn-ветки с апстрима?
И есть ли какая-то автоматизация коммита в svn (я правильно понял, что вы просто через отдельную WC коммиттите?)?
ветки которые мне нужны есть в git c префиксом svn_
и я их полноценно мержу с всеми остальными (в которых работаю)
автоматизации нету (меня это сейчас мало смущает т.к. в один SVN коммит отправляется 2-3 фичи/ветки из GIT, и я понимаю что они делают)
именно для такой автоматизации создан svn-git, сейчас я бы стал его использовать.
Возможно и переду в ближайшее время.
А можно вообще начать работу на локальной машине.
А ещё есть git-svn.
При этом:
а) Видна история коммитов внешних людей — видно кто/что/когда и зачем делал
б) Видно кто и когда поместил эти изменения в проект
в) Внешние разработчики могут легко перетягивать (merge'ить) к себе в рабочий репозитарий изменения в центральном хранилище, сохраняя актуальность своей копии проекта.
вы же не просто так делаете push, а проектируете поток своих изменений
squadette.habrahabr.ru/blog/40462/
почитайте
а гитовская, обновляя рефы по своему протоколу — теснее ориентирована с самой идеей хранения истории изменений
Вам говорят «эта машина способна проехать тысячу километров на одном литре бензина». Вы говорите «расскажите подробнее пример из практики, как вы проехали 1000 километров на литре бензина».
что тут можно «рассказать»?
«Да, я тоже проехал 1000 километров и потратил 1 литр бензина», что ли?
по-моему, этот «рассказ» будет отдавать имбецильностью
никто не мешает в Subversion коммитить один раз в неделю с комментарием «Уфф, пятница» :)
я не знаю, что на это ответить
могу головой об стену побиться, если вы все этого хотите
«будет, потому что может», и «не будет, потому что иначе не может» — какая пропасть в мировоззрении есть между этими вещами
быдлокодеров которым не вдолбишь что коммититься нужно часто. Если у них будет возможность не коммитится они и не будут пока не пнешь.Это относится и к написанию тестов. Они понимают что тесты имеют массу преимуществ. Но тут же надо мозгом шевелить.
Так же между прочим и отношении к веткам. Все программисты в офисе в лучшем случае об этом только слышали краем уха. Прошу их уже неделю прочесть свнбук по веткам. Отгадайте с трех раз хотя бы один прочел?
А как Вы работаете с SVN
— сколько коммитов Вы делаете в день?
— сколько бранчей обычно в репозитарии?
— сколько разработчиков в проекте?
если ответы на все эти вопросы < 5, то SVN вам вроде должно хватать.
а если нет, то готов рассказать что станет в Вашей жизни лучше если Вы перейдете на Git
Разработчиков 7 программеров + верстальщик
бранчей 4 штука, 3 из них trunk, branches и tags )))) Но будет конечно больше. Просто до сего момента с ветками один я работаю.
именно автомобильную метафору я и использовал
я задавал человека обычный набор вопросов по (простейшим) структурам данных. хэши да деревья, совершенно ничего из ряда вон выходящего.
человек же был программистом на пыхопэ, писал какие-то говносайты, и в какой-то момент заявил мне: «зачем вообще нужны эти структуры данных, мне вот они ни разу не потребовались за всю мою карьеру.»
«ну как же», говорю я — «представьте себе, что вам придётся писать какую-нибудь реально сложную систему, например систему распознавания движущихся объектов с видеозаписи. куда там без структур данных, к тому же гораздо более сложных.»
«ну мне пока что системы видео-распознавания писать не доводилось, а когда понадобится — выучу», гордо заметил товарищ.
я уж как мог постарался до него донести, что это не ему не просто «не доводилось», а на самом деле про него и подумают-то в последнюю очередь, потому что он самостоятельно и превентивно не удосужился изучить основы computer science.
то есть подход «так как я не участвую в формуле-1, то езжу на жигулях, а как меня пригласят в команду — так я сразу подкачаю скиллы-то» — он приводит к тому, что ни в какую формулу-1 Вас не пригласят
потому что сначала скиллы
а потом уже предложение
но в принципе конечно ничего зазорного в том, чтобы не участвовать в формуле-1 — нету :)))
А если прошел таки собеседование, делаешь все те же говносайты на пэхэпэ.
Вот когда вы напишете, что-то лучше пэхэпэ, тогда и сможете так небрежно о нем отзываться.
А узнать сообразительный парень или нет, можно узнать и не спрашивая основы.
Основы можно выучить, все можно выучить, но если человек дурак то ему основы не помогут.
молодец, прошёлся по всем комментом с минусом ;)
«сообразительный парень»!
P.S.: карму минуснуть забыл!
А вот то, что и другим не понравился, я не виноват.
Бывают конечно те еще кадры устраиваются на работу, прочитав книгу Котерева и хотят получать 40 тыс. руб. в месяц.
Мало того, я уже принял решение что один из моих собственных проектов я переведу на GIT. Недельки через две будет время.
ну ничего, я верю в хабр
акиры не подведут
«Я не использую» и «я не знаю».
я тоже на нескольких проектах использую Subversion, и в ближайшее время переходить не собираюсь (хотя кстати всегда можно прицепить рядом git svn, и никто
ничего
не заметит даже :))
И как вообще проще переехать с svn на git с сохранением истории (если это реально), и есть ли аналогичные утилиты типа черепахи?
входит непосредственно в дистрибутив и называется «git svn» :)
то есть
вы можете склонировать полную (или часть) историю изменений svn-репозитория и превратить её в гитовый репо.
соответственно возникнет двунаправленная связь между ветками в svn и ветками в этом git-репо
дальше можно а) свободно работать в гит-репо без ограничений. затем внесенные изменения на ветке закоммитить обратно в Subversion.
б) обновлять (инкрементально) содержимое гит-репо, доимпортируя новые коммиты из svn-репо. при этом внутри гита будет обычный merge-tracking, который позволит эти svn-коммиты безболезненно накатить.
то есть теоретически ваши коллеги могут не подозревать, что вы не пользуетесь Subversion :)
я это наблюдал непосредственно в продакшене
И ничего кстати, заметно времени и нервов экономил по сравнению с тем когда напрямую с SS работал.
но можно засетапить так, что дизайнеры сидят под svn/tortoisesvn, а девелоперы пользуются гитом
я думаю, что рано или поздно мы у себя так и сделаем
git.or.cz/gitwiki/GitSvnComparsion
markmcb.com/2008/10/18/3-reasons-to-switch-to-git-from-subversion/
товарищ
я подозреваю, что приблизительно четверть программистов на постсоветской территории начали пользоваться системами контроля версий так или иначе на основании моих трудов на эту тему.
ever heard of alexm.here.ru/cvs-ru/
? :)
Вы чего сказать-то хотите? :)
теоретически я должен чувствовать сострадание и уважение ко всем живым существам
но я, знаете, человек слабый
и поэтому мне сложно всерьёз воспринимать людей со столь чётким лейблом «Pioneriis Vacuumcephali» на лбу :)
постарайтесь написать другой комментарии, более умный :)
а этот сотрите, не позорьтесь :)
вам — безусловно респект за доступ к репозиториям cvs/svn, но если вы хотели потрясти своим длинным экспериенсом — нужно было с этого и начинать, а то перевод документации выглядит слабенько… :-)
так что ша, дружок
как там Предводитель Акира говорит — когда напишешь лучше — заходи
так что ша, дружок
как там Предводитель Акира говорит — когда напишешь лучше — заходи
1) Файл/каталог B _внутри_ репозитория создан с помощью чего-то вроде svn copy на основе, соответственно, файла/каталога A. Есть ли способ из такого подпроекта B черрипикнуть изменения в подпроект A с помощью git? Как в таком случае (раздвоения части проекта на несколько) поступают git`овцы? Неужели сразу, как только забрезжит такая возможность, выкидывают кусок изменений в субмодули (та ещё нетривиальная задача, поскольку, как минимум, все теги в субмодуле исчезнут/станут кривыми)?
/* По мне, так неподдерживание git`ом равноправных вложенных деревьев — самый большой его недостаток. С другой, стороны, понятно, для чего так сделано: ясность и производительность. */
2) Как с помощью git работать над драйвером linux из дистрибутива ядра так, что бы не тащить к себе в раздел всё дерево исходников linux в качестве working copy?
1) каждый проект — свой репозитарий
так что приходится выкидывать в суб-модули
про теги в суб-модуле, не знаю не юзал
2) никак, т.к. идеология git — работать со всем проектом, а не с файлами/директориями
и проект ведется соответственно этой идеологии, что учит нас разрабатывать не кусочки, а законченные решения.
про теги имелось в виду — то, что при любой переписи истории, криптографические теги будут испорчены, поскольку они созданы для другого коммита/дерева.
2) получается, не всё, что может SVN. Он хорош именно проработанностью в смысле use cases (с учётом, что когда SVN проектировался, мерджи и DVCS-фичи редко какие проекты использовали). То, что исполнителю можно дать определённый небольшой участочек работы — это очень удобно.
Понятно, что с этими ограничениями борются планированием структуры проекта, но SVN удобен тем, что можно именно разрабатывать активно (впрочем, в других аспектах git рулит в этом отношении ещё больше).
Это любо два разных проекта, либо один.
У нас в репозитарии 4 экстернела, 2 из них реально отдельные проекты, и они лежать отдельно. И от их иногда «неудачных» обновлений страдают лишь они сами. И поэтому у них отдельные репозитарии.
2 других фактически часть нашего проекта, которую вынесли для разработки «ВНЕ» (участочки работы, блин), и это два нам постоянно все ломают. И если бы разработчики этих двух проектов, работали со всей системой «в целом» такого бы не было.
Пример с драйверами в Linux показательный, т.к. драйвера, поддерживающие модульное исполнение, как правило, — независимое от основного ядра ПО, размещённое в отдельном каталоге. В svn для их форка достаточно просто сделать svn copy, а в git для этого придётся переписывать историю коммитов, с выкидыванием из changeset`ов не относящихся к данному драйверу файлов. При этом история изменений в случае SVN сохранится в виде «бесплатного» приложения к копированию, а в случае git придётся следить за копированиями, склейками и переименованиями файлов вручную (можно скрипт написать, но пока общеупотребимого нет). Поэтому, несмотря на централизованность, SVN, я считаю, остаётся более динамичным в плане разработки, естественно, в случае, когда распределённости не требуется впрямую (<20 разработчиков из одной конторы над одним [под]проектом). Но вот дикая сложность мерджей угнетает, особенно, когда апстрим работает под версией <1.5.
Опять же, описанные ситуации довольно редкие и относятся больше к скриптовым, а не транслируемым в машинный код проектами. Так что, опять же специфика предмета проекта влияет на выбор «правильной» VCS/SCM.
Кстати, вроде бы в Mercurial с расширением forest, указанная проблема решается.
Отсутствие мусора это +. Не существенно, но все таки некоторый геморрой убирает.
P.S. Уфф, извиняюсь за свой пост, но кажется из-за меня тут холивар собирается :)
Так вот кажется не кажется а ветки именно для этого и существуют. Там советовали правильно. Переходить на другую систему только из за того что ветки показались чем то страшным наверное решение принятое с горяча. Нельзя так панически боятся нового. Наоборот наверное новое должно привлекать пытливые умы программистов)))
вот у меня проект 5.5 мегабайт, а mercurial репозитарий — 1.3. (50 коммитов правда пока что).
если ты просто привык коммитить уже сделанные вещи, и ты успеваешь сделать итерацию за день то ничем.
я использую иначе:
— каждая фича — свой бранч
— каждое законченное изменение (функция, шаблон, правило) — коммит (в среднем я комичу раз в 10 минут)
— в работе 5-10 фичей одновременно, причем я могу переключится с одной на другую за пару секунд
— в транк попадают только законченые и протестированые фичи (тестирование и транк на др. хостах), тут отлично применяется распределенность
причем GIT сам навязывает такой стиль разработки
можно ли все это также просто и легко сделать в SVN???
а если в проекте 5-10 человек?
ЗЫ
ну и специально для тебя, в TM есть отличный GIT.bundle, благодаря которому можно не вникать в устройство GIT'а, а просто его использовать :)
Теперь более или мение представляю себе чем меня может GIT захватить. Изменением стиля разработки. Ведь с ветками SVN создавать ветки на каждый чих накладно, поэтому часть кода правится в транке. Но ясно же что это компромисс.
Ну и стиль использования «стабильный trunk» можно реализовать и в svn.
а расход на использование веток, это то что ветки приходся тянуть с сервера каждый раз
это не FUD, я лично просто нервничаю от этой идеи
мне для полного счастья ещё риска выгребания проблем от апгрейда не хватает
тошним на svnmerge :))
а как насчёт tags
просто перед merge
тянешь tag, называешь
как удобно и будет вам
счастие
1. текущая директория
2. куда в действительности эта директория смотрит (куда был сделан свитч)