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

Эта заметка будет интересна тем кто работает с 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 тоже обновились.

Итак, сегодня речь пойдет о подключении внешних библиотек (суб-проектов) в основные проекты с использованием Subversion.
По старой доброй традиции, в качестве клиента для работы с SVN будет использоваться давно полюбившийся нам TortoiseSVN.

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