Хабрахабр / Комментарии к посту «Работа с ветками в SVN. Изменения в версии 1.5.» в блоге «Системы управления версиями»

20.12.2008 17:57:16 t3ran

t3ran — Sat, 20 Dec 2008 17:57:16 GMT

Пасиба! Как раз сейчас работаю с svn и ветками:)

26.11.2008 20:19:50 fractalizator

fractalizator — Wed, 26 Nov 2008 20:19:50 GMT

Гиту для хранения репозитория на серверя хватит и простого ssh (но лучше, чтоб с ключиками), ничего для этого настраивать не надо.

А можно вообще начать работу на локальной машине.

А ещё есть git-svn.

26.11.2008 07:42:17 allter

allter — Wed, 26 Nov 2008 07:42:17 GMT

Вроде понятно, спасибо!

26.11.2008 07:38:37 allter

allter — Wed, 26 Nov 2008 07:38:37 GMT

Вообще-то, прямо зависимые. Одно дело рассматривать сферические мерджи в вакууме (что SVN, что git с такими _не_ справляются — то контекста им не хватает, то ещё чего), другое — реальные ситуации правки исходников и бинарников конкретного проекта.

Пример с драйверами в Linux показательный, т.к. драйвера, поддерживающие модульное исполнение, как правило, — независимое от основного ядра ПО, размещённое в отдельном каталоге. В svn для их форка достаточно просто сделать svn copy, а в git для этого придётся переписывать историю коммитов, с выкидыванием из changeset`ов не относящихся к данному драйверу файлов. При этом история изменений в случае SVN сохранится в виде «бесплатного» приложения к копированию, а в случае git придётся следить за копированиями, склейками и переименованиями файлов вручную (можно скрипт написать, но пока общеупотребимого нет). Поэтому, несмотря на централизованность, SVN, я считаю, остаётся более динамичным в плане разработки, естественно, в случае, когда распределённости не требуется впрямую (<20 разработчиков из одной конторы над одним [под]проектом). Но вот дикая сложность мерджей угнетает, особенно, когда апстрим работает под версией <1.5.

Опять же, описанные ситуации довольно редкие и относятся больше к скриптовым, а не транслируемым в машинный код проектами. Так что, опять же специфика предмета проекта влияет на выбор «правильной» VCS/SCM.

Кстати, вроде бы в Mercurial с расширением forest, указанная проблема решается.

25.11.2008 22:34:17 RVK

RVK — Tue, 25 Nov 2008 22:34:17 GMT

Кажется пошли темы уже не зависимые от сабжа. Организация разработки большая, интересная тема. Это отдельный блог, не видел есть ли он на хабре, но мысли по этому поводу у меня есть и статью хочу написать. Но после 1 декабря.

25.11.2008 22:23:49 KBA

KBA — Tue, 25 Nov 2008 22:23:49 GMT

я не верю в «участочек работы» в рамках большого проекта, в отрыве от всего проекта.

Это любо два разных проекта, либо один.

У нас в репозитарии 4 экстернела, 2 из них реально отдельные проекты, и они лежать отдельно. И от их иногда «неудачных» обновлений страдают лишь они сами. И поэтому у них отдельные репозитарии.

2 других фактически часть нашего проекта, которую вынесли для разработки «ВНЕ» (участочки работы, блин), и это два нам постоянно все ломают. И если бы разработчики этих двух проектов, работали со всей системой «в целом» такого бы не было.

25.11.2008 16:59:47 Paul

Paul — Tue, 25 Nov 2008 16:59:47 GMT

Зачем тянуть, можно сделать switch.

25.11.2008 16:26:32 allter

allter — Tue, 25 Nov 2008 16:26:32 GMT

1) и реально выкидываются (случаи, когда подпроект существует уже несколько месяцев не в счёт), или это вы предположили из общих соображений?

про теги имелось в виду — то, что при любой переписи истории, криптографические теги будут испорчены, поскольку они созданы для другого коммита/дерева.

2) получается, не всё, что может SVN. Он хорош именно проработанностью в смысле use cases (с учётом, что когда SVN проектировался, мерджи и DVCS-фичи редко какие проекты использовали). То, что исполнителю можно дать определённый небольшой участочек работы — это очень удобно.

Понятно, что с этими ограничениями борются планированием структуры проекта, но SVN удобен тем, что можно именно разрабатывать активно (впрочем, в других аспектах git рулит в этом отношении ещё больше).

25.11.2008 16:19:20 KBA

KBA — Tue, 25 Nov 2008 16:19:20 GMT

не совсем так.
ветки которые мне нужны есть в git c префиксом svn_

и я их полноценно мержу с всеми остальными (в которых работаю)

автоматизации нету (меня это сейчас мало смущает т.к. в один SVN коммит отправляется 2-3 фичи/ветки из GIT, и я понимаю что они делают)

именно для такой автоматизации создан svn-git, сейчас я бы стал его использовать.
Возможно и переду в ближайшее время.

25.11.2008 16:07:58 KBA

KBA — Tue, 25 Nov 2008 16:07:58 GMT

зато, до недавнего времени были расходы на merge
а расход на использование веток, это то что ветки приходся тянуть с сервера каждый раз

25.11.2008 16:04:57 KBA

KBA — Tue, 25 Nov 2008 16:04:57 GMT

я согласен про этот недостаток

1) каждый проект — свой репозитарий
так что приходится выкидывать в суб-модули
про теги в суб-модуле, не знаю не юзал

2) никак, т.к. идеология git — работать со всем проектом, а не с файлами/директориями
и проект ведется соответственно этой идеологии, что учит нас разрабатывать не кусочки, а законченные решения.

25.11.2008 15:48:26 RVK

RVK — Tue, 25 Nov 2008 15:48:26 GMT

Вот они как раз таки советуют выбирать золотую середину, не создавая веток на каждую плевую задачу.

25.11.2008 15:20:00 allter

allter — Tue, 25 Nov 2008 15:20:00 GMT

Т.е. у вас есть master — стабильная общая ветка, а svn вы используете лишь в качестве источника для черрипикинга?

А куда зеркалятся svn-ветки с апстрима?

И есть ли какая-то автоматизация коммита в svn (я правильно понял, что вы просто через отдельную WC коммиттите?)?

25.11.2008 15:07:27 allter

allter — Tue, 25 Nov 2008 15:07:27 GMT

Накладных расходов «веток на каждый чих» в SVN нет (они сами хвалятся в документации своим O(1) ). Если не нравится засорение пространства имён, то просто удаляйте такие ветки после чихов.

Ну и стиль использования «стабильный trunk» можно реализовать и в svn.

25.11.2008 15:01:27 allter

allter — Tue, 25 Nov 2008 15:01:27 GMT

В ближайшее время svk в текущем виде устареет из-за отсутствия поддержки merginfo апстрима. :( А Foror`у, действительно, надо было просто создать личную ветку, а утром её закончить, реинтегрировать и удалить (если она ему глаза замозолила).

25.11.2008 14:52:49 KBA

KBA — Tue, 25 Nov 2008 14:52:49 GMT

я сейчас не использую svn-git (я как то побоялся его юзать, т.к. плохо знал устройство Git и как с ним работать)

сейчас использую одну ветку git как транк SVN куда подливаю все изменения.

когда надо закомитить в svn я просто грепаю лог git'а
и пишу что надо в комментарии к комиту

25.11.2008 14:52:43 allter

allter — Tue, 25 Nov 2008 14:52:43 GMT

Да? Предложите тогда решение для следующих use case:
1) Файл/каталог B _внутри_ репозитория создан с помощью чего-то вроде svn copy на основе, соответственно, файла/каталога A. Есть ли способ из такого подпроекта B черрипикнуть изменения в подпроект A с помощью git? Как в таком случае (раздвоения части проекта на несколько) поступают git`овцы? Неужели сразу, как только забрезжит такая возможность, выкидывают кусок изменений в субмодули (та ещё нетривиальная задача, поскольку, как минимум, все теги в субмодуле исчезнут/станут кривыми)?

/* По мне, так неподдерживание git`ом равноправных вложенных деревьев — самый большой его недостаток. С другой, стороны, понятно, для чего так сделано: ясность и производительность. */

2) Как с помощью git работать над драйвером linux из дистрибутива ядра так, что бы не тащить к себе в раздел всё дерево исходников linux в качестве working copy?

25.11.2008 14:22:44 allter

allter — Tue, 25 Nov 2008 14:22:44 GMT

Кстати, было бы хорошо, если бы вы написали, как работается с git-svn. Насколько удобно «интегратору» сидеть на git «сбоку» от основного SVN (поддерживающего или нет merge tracking)?

А то я тут поработал с svk (работая с //local через рабочие копии svn клиента) и merge tracking — настолько всё было тяжело из-за того, что история мерджей в разных форматах и из-за того, что svk необратимо склеивает несколько разноплановых коммитов в один мердж-коммит. :(

А вот используя только git (есть опыт) всё так удобно и логично. Главное всегда помнить философию git — манипулирование не срезами деревьев в разные моменты (хотя эта фича тоже основная в git), а манипулирование патчами в контексте предыдущей истории проекта.

25.11.2008 13:06:14 evilbloodydemon

evilbloodydemon — Tue, 25 Nov 2008 13:06:14 GMT

не «зато», а «к сожалению»

25.11.2008 12:52:48 maxcom

maxcom — Tue, 25 Nov 2008 12:52:48 GMT

зато у svn там вообще истории нет, только последнее состояние репозитория

25.11.2008 12:32:21 lomeo

lomeo — Tue, 25 Nov 2008 12:32:21 GMT

А я на каждый чих — документы, скриптики — git init и вперёд :-)

25.11.2008 12:30:51 lomeo

lomeo — Tue, 25 Nov 2008 12:30:51 GMT

Тем, что сценариев работы теперь больше, чем один. Классический — один репозиторий считать центральным (сервер), а прочие — клиентскими копиями — всего лишь один из возможных вариантов. Годится, когда есть один продукт и мы его иногда выпускаем. Возможны же и иные случаи.

Вот пример — в Git-репозитории у меня хранятся мои персональные настройки (xmonad, vim, разные скрипты и т.д.). Есть репозиторий на рабочей машине, есть на домашней. Они в чём то должны отличаться — всё таки я пользуюсь не совсем одинаковым набором программ дома и на работе. Но большей частью они похожи, и я могу нужные мне изменения переливать из одного места в другое. В svn наверное, надо было заводить ветки.

Классический сценарий наиболее часто используемый я думаю (у меня не очень большой опыт Git-а). Он позволяет управлять доступом к репозиторию — скажем в master (это типа trunk) может лить только master manager или назовём его master master :) Те у кого нет доступа, могут слать патчи и т.д. Это, правда, можно сделать и в SVN, но разница здесь в том, что у тебя свой репозиторий, с которым ты можешь работать, подключаясь к центральному только для того, чтобы залить нужные изменения. Лёгкая работа с ветками этому очень помогает. За всеми рабочими копиями, разумеется, следить не надо.

В общем, мне описать очень трудно, просто попробуй.

25.11.2008 11:15:06 evilbloodydemon

evilbloodydemon — Tue, 25 Nov 2008 11:15:06 GMT

ну он же сжатый, а рабочая копия svn — нет.
вот у меня проект 5.5 мегабайт, а mercurial репозитарий — 1.3. (50 коммитов правда пока что).

25.11.2008 10:18:05 maxcom

maxcom — Tue, 25 Nov 2008 10:18:05 GMT

меньше? там полная копия репозитария со всей историей

25.11.2008 10:05:17 middle

middle — Tue, 25 Nov 2008 10:05:17 GMT

Она в моём списке TODO сразу же после статьи «Запорожец vs лендровер».

25.11.2008 10:05:11 grib

grib — Tue, 25 Nov 2008 10:05:11 GMT

Можно и запомнить, но ещё и в тексте исправить бы…

25.11.2008 09:56:07 KBA

KBA — Tue, 25 Nov 2008 09:56:07 GMT

тут можно только попоробовать
причем не обязательно отказываться от SVN есть www.kernel.org/pub/software/scm/git/docs/git-svn.html

и тогда SVN будет для Вас как еще один удаленый репозитарий.

Я сам так колебался, потом попробовал Hg, потом Git. Сейчас Git меня вполне устраивает. Хотя основной транк находится в SVN, для меня это просто еще одна ветка в Git.

25.11.2008 09:50:31 KBA

KBA — Tue, 25 Nov 2008 09:50:31 GMT

ну они находятся только в корне проекта, меньше по размеру, и легче удаляются :)

25.11.2008 09:38:10 maxcom

maxcom — Tue, 25 Nov 2008 09:38:10 GMT

а метаданные типа .git? ;-)

25.11.2008 09:37:34 maxcom

maxcom — Tue, 25 Nov 2008 09:37:34 GMT

заслуженный пенсионер? ;-)

25.11.2008 09:22:16 maxcom

maxcom — Tue, 25 Nov 2008 09:22:16 GMT

удобно контролировать работу внештатников или каких-нибудь внешних разработчиков — они работают в своем репозитарии, выдавая коммиты на проверку разрабочикам проекта. При одобрении изменения помещаются в центральный репозаторий.

При этом:

а) Видна история коммитов внешних людей — видно кто/что/когда и зачем делал
б) Видно кто и когда поместил эти изменения в проект
в) Внешние разработчики могут легко перетягивать (merge'ить) к себе в рабочий репозитарий изменения в центральном хранилище, сохраняя актуальность своей копии проекта.

25.11.2008 09:10:37 squadette

squadette — Tue, 25 Nov 2008 09:10:37 GMT

ну, слабенько — не слабенько, а официальной документацией в русском Интеле этот перевод был

так что ша, дружок

как там Предводитель Акира говорит — когда напишешь лучше — заходи

25.11.2008 09:08:32 RVK

RVK — Tue, 25 Nov 2008 09:08:32 GMT

Спасибо.
Теперь более или мение представляю себе чем меня может GIT захватить. Изменением стиля разработки. Ведь с ветками SVN создавать ветки на каждый чих накладно, поэтому часть кода правится в транке. Но ясно же что это компромисс.

25.11.2008 09:01:42 RVK

RVK — Tue, 25 Nov 2008 09:01:42 GMT

Я сам случай из жизни придумал. Правда я еще не рехнулся что бы в отпуске програмить, но бывают и такие люди.

Повторяю, не пытаюсь доказать что гит хуже свн. Лучше и намного, уже убедился. Я пытаюсь для себя понять стоит ли сейчас идти к одмину и просить его перевести репозиторий на гит, а потом доказывать программистам что они просто еще не осознали своего счастья

25.11.2008 08:59:48 squadette

squadette — Tue, 25 Nov 2008 08:59:48 GMT

в настроенный

вы же не просто так делаете push, а проектируете поток своих изменений

squadette.habrahabr.ru/blog/40462/
почитайте

25.11.2008 08:58:27 RVK

RVK — Tue, 25 Nov 2008 08:58:27 GMT

Здорово и правда. Только вот же блин, ну не работаю я дома и ноут с собой не таскаю. Дома нужно отдыхать. Впрочем дома у меня есть интернет и доступ в рабочий репозиторий. Хотя иногда может пригодится, не спорю. Например я был 2 недели в санатории где инета небыло. Мог бы кодить без проблем, а вернувшись в Москву закомитить.

25.11.2008 08:53:02 squadette

squadette — Tue, 25 Nov 2008 08:53:02 GMT

25.11.2008 08:52:01 squadette

squadette — Tue, 25 Nov 2008 08:52:01 GMT

это тупая файловая распределенность

а гитовская, обновляя рефы по своему протоколу — теснее ориентирована с самой идеей хранения истории изменений

25.11.2008 08:51:37 RVK

RVK — Tue, 25 Nov 2008 08:51:37 GMT

Комитится могу и чаще тут лимита нет.
Разработчиков 7 программеров + верстальщик
бранчей 4 штука, 3 из них trunk, branches и tags )))) Но будет конечно больше. Просто до сего момента с ветками один я работаю.

25.11.2008 08:50:48 zerkms

zerkms — Tue, 25 Nov 2008 08:50:48 GMT

забыл тег irony, думал и так поймёте
вам — безусловно респект за доступ к репозиториям cvs/svn, но если вы хотели потрясти своим длинным экспериенсом — нужно было с этого и начинать, а то перевод документации выглядит слабенько… :-)