Системы управления версиями *

Кажись, я просёк то, что нигде никто явно не пытается писать — а мне без этого как-то непонятно было. У меня довольно большой опыт работы в VSS и некий опыт присматривания к SVN. А сейчас вот и к GIT-ам всяким присматриваюсь.

На страничке mercurial.selenic.com/wiki/UnderstandingMercurial в конце сказано, что если вы думаете держать в одном репозитории HG несколько родственных проектов, как привыкли в системах типа SVN, то лучше одумайтесь, ибо HG на это не рассчитан. Похоже это потому, что он всегда работает со всей рабочей папкой в целом.

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

Введение

В статье рассматриваются несколько проблем (и полезных возможностей) при работе с mercurial и предлагаются варианты их решения.

Несколько проектов на одном фреймворке

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

Что же делать?

Доброго времени пребывания, уважаемые Хабровцы 8)
Наткнулся я недавно, на бескрайних просторах, на очень полезную и долгожданную штуковину. Что за штуковина — читай сабж.

Выглядит всё это, как всем известный TortoiseSVN для Windows. Только называется RabbitVCS и уже для Linux.
Если не верите, смотрите скриншоты :)

Спешу рассказать хабрасообществу о, относительно новом, дьявольски завораживающем проекте Gource которое еще не упоминалось. Это приложение позволяет визуализировать историю изменений в системе контроля версии. Отрисовывает невероятно красиво при помощи OpenGL.

Добрейшего.

Набрёл на неплохой текст от команды Microsoft Team Foundation Server: Branching Guidance
Будущим и нынешним пользователям обозначенной системы предлагается:

1. проникнуться важностью ветвления и слияния изменений для работы больших команд;
2. узнать, какие типы веток бывают и как строить изоляцию работы на их основе;
3. посмотреть на практических примерах как надо правильно отращивать и мёржить изменения.

 

Два года назад Линус Торвальдс рассказал представителям Google об использовании GIT (распределённой системы контроля версий) для ядра Linux. Посчитав, что многие могут пропустить эту интересную лекцию по причине незнания языка, я осмелился озвучить её по-русски.



а так же плейлист целиком.

Git это еще одна системы для управления исходным кодом, аналогичная subversion, cvs и другим. Почему аналогичная, а не «новая», «быстрая» и тп? SCM (source code management) прежде всего инструмент, который позволяет выполнять операции необходимые для одного разработчика и команды в целом. При каждый инструмент имеет свои достоинства и недостатки.

В этой статье мы сосредоточимся на основных функциях, без сравнительного анализа (чтобы не повторять миллионы заметок в web). И покажем пример, как применять git при работе с subversion.

Итак, сразу опишу нашу ситуацию и потом объясню почему дал этой статье такое глупое название :-)

Наша команда из 4х человек работает на одном проекте (пока не буду говорить, что за проект, надеюсь, напишу о нем позже)

У нас было 3 SVN ветки: Production (стабильная ветка, которая обслуживает запросы пользователей), Staging (промежуточная ветка), Trunk (девелоперская ветка).

Эта заметка будет интересна тем кто работает с subversion и должен переносить исходники из репозитория на сайт в «ручную», через консоль.
Не много предыстории.
Я достаточно часто обновляю файлы для нашего проекта Закладки на картинки (picfor.me) и для этого пользовался командой svn export …, но вот беда если мне надо закачать только изменения между ревизиями, то в консоли это сделать не так просто:

1. $ svn export  -r1123:1167 . /tmp/export_dir
2. svn: Revision range is not allowed

Есть конечно решений, если использовать клиента TortoiseSVN, вот статья с хабра где это описано.

Я же придумал решение для консоли.

Как сообщает Google Code Blog, в скором времени хостинг для опенсорсных проектов от гугла будет поддерживать Mercurial наряду с Subversion для контроля версий.

Разработчики тщательно выбирали между разными распределенными системами, и в конце концов остановили выбор именно на mercurial, а процессу выбора между mercurial и git посвящен этот интересный документ. Mercurial победил в «конкурсе», поскольку:

• он лучше интегрировался в инфраструктуру гугла: меньше сложностей с хранением данных, проще и «чище» HTTP интерфейс;
• удобнее для windows-пользователей ( официальный windows-порт git использует cygwin);
• кривая обучения менее, гм, кривая.

Гуглоразработчикам пришлось частично переписать mercurial, вместо стандартного дискового хранилища у них используется BigTable.

Простыми словами и с большим количеством картинок на примере Eclipse рассказывается, как сделать svn merge. Статья будет полезна тем, у кого выполнение слияния веток еще не стало повседневной частью работы.

 

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

Upd: В названии статьи хоть и фигурирует SVN, но советы, изложенные в ней, подходят ко всем известным мне системам кондроля версий. Стоит так же заметить, что советы направлены в основном на командную разработку.

Что нового:

• Улучшенное управление данными аутентификации (сохранение данных аутентификации в KWallet или Gnome Keyring, сохранение ключей к SSL сертификатам, запрос подтверждения перед сохранением паролей в незашифрованном виде)
• Новый формат URL — поддержка путей относительно корня (root relative URLs)
• Расширение svn:externals: поддержка файлов в svn:externals
• Определение tree conflicts — конфликтов на уровне структуры директорий
• Улучшения в способе хранения данных — репозитарий будет занимать меньше дискового пространства
• Новые Python-bindings
• Улучшено интерактивное разрешение конфликтов в комманд-лайн клиенте
• Параметр --set-depth команды update поддерживает новое значение exclude, позволяющее исключать определенные ветки из рабочей копии
• Поддержка логирования в svnserve
• Новый синтаксис HTTP URI позволяет получать доступ к определенным ревизиям:

  http://host/repos/path?[p=PEG][&r;=REV]

• Улучшения комманд-лайн клиента: команда log теперь поддерживает несколько параметров -r и -с за один вызов; новый параметр --trust-server-cert
• Изменения в API
• Исправлены ошибки

— Зачем ты, Белка, летишь за мной, Кабаном?
— Не знаю, Кабан! Приказ Хорька. Как понял? Приём.
— Ни хера не понял! Какого Хорька, Белка? Я Кабан. Кто такой Хорёк? Кто это? Приём.
— Кабан, ты дятел! Как понял? Приём.
— Понял тебя, Белка. Я — Дятел. Повторяю вопрос про хорька. Кто это?
— Кабан, сука, ты всех заманал, лети вперёд молча! Конец связи.
Виктор Шендерович

Как известно, Subversion не умеет отслеживать переименования файлов. Согласно документации, команда svn move равносильна svn copy с последующим svn delete. Такое поведение вызывает большие проблемы при слиянии веток. Рассмотрим способы их решения.

Некоторое время назад я, разбираясь с различными системами контроля версий, наткнулся на видео битвы трех гигантов — Git, Mercurial и Bazaar. Ни один из них не уступает другому ни в поклонниках, ни в функционале. Видимо пришло время выяснить, кто же из них лучшим в драке. Судя по решимости участников — драка будет нешуточной :)

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

Продолжение этой статьи

Долгое время в ветках SVN был один существенный недостаток. Система не помнила мержей, и программисту приходилось самостоятельно заботиться о том, что бы сохранить номер ревизии, когда происходило копирование изменений из транка. Проблема частично решалась добавлением комментариев в лог, но все таки это было чревато ошибками, и целиком ложилось на совесть программиста.
В версии 1.5, наконец-то, программисты Subversion выполнили свое давнее обещание, и добавили несколько полезных фич для работы с ветками.
Итак, в версии 1.5 команда merge обзавелась двумя новыми опциями: --record-only и --reintegrate.
Теперь ответственность за контроль копирования изменений ложится целиком на плечи SVN (merge tracking), а программист может легко, и без боязни выполнять merge так часто, словно это команда update.

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

После того как вы прочли статью о ветках в svnbook, вы уже понимаете для чего нужны ветки, как с ними работать и в каких случаях их необходимо использовать. В принципе, после этого, то, что написано под катом вам уже скорее всего не нужно. Но если вам было лень читать, то может текст ниже вас заинтересует, и вы все таки прочтете статью документации. А может, просто поможет вам лучше понять то, что только что прочли в svnbook-е.

Из ключевых нововведений:

• Отслеживание слияний (мержей)
• Sparse checkouts (ограничение чекаутов по глубине дерева)
• Интерактивное разрешение конфликтов
• Поддержка списков изменений (changelists)

Также увеличение производительности и исправлена куча ошибок. Ура, товарищи!

Бинарников пока нет:

Probably the number one thing people are looking for is binaries. I assure you they are coming. CollabNet's binaries are certified and that process cannot begin until the official release is made. So our team is hard at work building and certifying the binaries. The tentative certification schedule is:
Linux: June 20
Windows: June 24
Solaris: June 26

Фанаты могут собрать сами из исходников.

PS: katremer в комментариях подсказал, что TortoiseSVN уже выпустила бинарники.
VisualSVN тоже обновились.