Пресс-релиз:

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

Но с годами системой по умолчанию стала Git. Она помогает командам всех размеров работать быстрее, поскольку они становятся более распределенными.

Сейчас у нас на платформе больше 10 миллионов зарегистрированных пользователей. Мы находимся в точке нашего роста, где мы проводим более глубокую оценку рынка и того, как мы можем наилучшим образом поддержать наших пользователей в будущем.

После долгих размышлений мы решили удалить поддержку Mercurial из Bitbucket Cloud и его API. Функции и репозитории Mercurial будут официально удалены из Bitbucket и его API 1 июня 2020 года.

Источник

В этой статье сравним с технической точки зрения самые известные системы управления версиями (в будущем планируем расширить список):

1. Первое поколение
   
   • SCCS (Source Code Control System)
   • RCS (Revision Control System)
2. Второе поколение
   • CVS (Concurrent Versions System)
   • SVN (Apache Subversion)
3. Третье поколение
   • Git
   • Mercurial

Очередная (2015, 2012, 2011, 2010, 2009) перепись в сфере VCS.

Всем привет! Уже на следующей неделе в OTUS стартует «Супер-практикум по использованию и настройке GIT». Этому я и решил посвятить сегодняшнюю публикацию.

---

Введение

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

 

Как часто бывает, зацепив одну, на первый взгляд, маленькую тему, с желанием быстро все узнать и все настроить, приходится закапываться в дремучие дебри и читать не одну статью и/или мануал. Так и получилось у меня в этот раз. Изначально было желание просто узнать, как обновлять порты (или исходные тексты портов) чтоб при желании, устанавливать не устаревшее ПО, но пришлось закопаться немного по глубже.
Эта статья предназначена только для новичков во FreeBSD, опытные профи тут вообще ни чего нового, думаю, для себя не найдут. По этому, если вы на «ты» с этой системой, можете смело пропускать дальнейший текст.
Информации на эту тему хватает, но из 6-10 заметок и статей я взял, так скажем, лучшие наработки и опыт, и записал их в одну, с ссылками на более полные статьи, так что при желании можно получить более подробную информацию по каждому пункту.
Содержание статьи:
1) Выбор ПО для обновления исходных текстов.
2) Процесс обновления исходных текстов системы и портов.
3) Обновление системы(ядро и мир).
4) Обновление портов при помощи pkg_*, portupgrade, portdowngrade.
5) Заключение
6) Дополнительная литература.

Блэкберри (дальше ББ) в России остается экзотикой, но еще экзотичнее ББ звучит в сочетании c GPL. Оказывается приложения для ББ можно разрабатывать вообще без затрат на средства разработки или лицензии. Распостранять приложения не обязательно через ББ App Store, так что ничто не мешает выпускать их под GPL. С Apple или WP7 экосистемой без jailbreak так не получится (пример — Videolan ). Я расскажу на своем примере, как бесплатно настроить платформу для разработки, тестирования и установки ББ приложений на Java в группе.

Парни из EdgeCase создали сайт gitimmersion.com, посетив который вы сможете познать фундаментальные азы Git, там предлагается пройти курс из 52 шагов, в каждом из которых описываются разные аспекты использования Git. Так, переходя от простого к сложному, можно влиться в число активных пользователей этой VCS.

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

Какие системы контроля версий Вы используете (для собственных проектов и для работы)?

Очередная (2012, 2011, 2010, 2009) перепись в сфере VCS.

Github — важная часть жизни современного разработчика: он стал стандартом для размещения opensource-проектов. В «2ГИС» мы используем гитхаб для разработки проектов web-отдела и хостинга проектов с открытым кодом.

Хотя большинство из нас пользуются сервисом практически каждый день, не все знают, что у него есть много фишек, помогающих облегчить работу или рутинные операции. Например, получение публичного ключа из URL; отслеживание того, с каких сайтов пользователи приходят в репозиторий; правильный шаринг ссылок на файлы, которые живут в репозиториях гитхаба; горячие клавиши и тому подобное. Цель этой статьи — рассказать о неочевидных вещах и вообще о том, что сделает вашу работу с гитхабом продуктивнее и веселее (я не буду рассматривать здесь работу с API гитхаба, так как эта тема заслуживает отдельной статьи).

Содержание

• Трюки с URL
• Горячие клавиши
• Тикеты и пулл-реквесты
• Github markdown
• Аккаунт
• Работа с репозиториями
• Поиск кода
• Командная строка и Github
• User scripts
• Github-вандализм
• Дополнительные Github-ресурсы
• Полезные ссылки

У Git есть строгие обязательства по обратной совместимости: многие продвинутые возможности скрыты за разнообразными опциями, а не применяются как поведение по умолчанию. К счастью, Git также поддерживает и алиасы, так что вы можете создавать свои собственные команды, которые делают всю характерную для Git магию. Под катом — подборка полезных (или как минимум забавных) алиасов, определённых в моём .gitconfig.

Предисловие от переводчика

На протяжении многих лет разработки ПО, будучи участником многих команд, работая с разными хорошими и опытными людьми, я часто наблюдал (да и чего греха таить, до определенного момента — создавал) одну и ту же проблему — тотальный бардак в репозитории. Каждый писал комментарии к коммитам в своем стиле (и хорошо, если постоянно в одном); половина комментариев была бесполезна (из разряда "это мост"), половина оставшейся половины — едва понятна.

И вот в один прекрасный момент я увидел данную статью, до перевода которой у меня наконец дошли руки. Всего 7 простых и коротких правил, и — о чудо — смотреть на историю коммитов стало не только полезно, но и приятно. Ничего революционного, все довольно очевидно, но сформулировано и резюмировано просто отлично.

Это всё же случилось. Недавние сливы оказались правдой.

Факт продажи официально подтвердили в своих блогах и GitHub, и Microsoft.

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

В примерах будет использоваться Subversion, хотя все рекомендации полностью применимы к любой другой системе контроля версий.

Грубо разделим фазы разработки проекта на три — дебют, миттельшпиль и эндшпиль.

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

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

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

Время от времени появляются новые задачи либо необходимость в решении старых задач новыми способами — тогда возникает потребность в дополнительном программном обеспечении. Что делать, если вам нужна новая программа для Linux? Попробую описать некий алгоритм.

Не все сайты делаются студией и после отдаются заказчику.

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

Тут и без бинокля видно, что неплохо бы использовать для хранения php и html кода репозиторий.

Но как это сделать правильней?
С дизайнерами и программистами все достаточно просто, они разрабатывают код на локальных машинах и изменения вносят в репозиторий. Можно даже настроить cron, чтобы периодически последние изменения из репозитория выкладывались на online сайт.

Но как быть с контентом?
Контент меняется только на online версии, чтобы не усложнять дело синхронизацией данных из разных БД. Но не весь контент хранится в базе, часто CMS контент статических страниц хранят в .php файлах, из-за чего появляются новые файлы и изменения, которые приходится периодически с «online» переносить в репозиторий, и делать это вручную во избежание конфликтов версий.

Интересно, кто сталкивался и как решал подобные задачи.

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

Плюс, со все большей стандартизацией форматов файлов и все большим распостранением XML-форматов, возможность сравнения версий будет входить все больше в обиход. Возможность сравнивать документы уже есть в Microsoft Word, например.

Итак, задача. Создать возможность работать над одним документом (или группой документов) распределенной команде. Фактически, расширить SVN или CVS для нужд бизнесов, не только программистов.

Дополнительные требования:
Расширенные возможности управления правами доступа
Доступ через веб без использования локальной файловой системы
Хранение мета-данных о файлах: метки, тэги, ассоциации
Автоматическое резервное хранение

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

Схема решения очевидна:

Первому, кто решит эту задачу, достанется приз в виде локальной временной монополии на рынке. Желательно, «решит» сразу с вопросом сравнения версий для всех основных форматов. А не только на уровне прав. То есть, охватит как можно большую площадь справа налево.

Или может, кто-то знает уже готовую платформу для этого?
Кто-то пользуется Sharepoint? Можете рассказать, как это устроено у вас?

 

Если Вы работали с ClearCase, а затем перешли на CVS, то Вам наверное очень не хватает ClearCase Version Tree Browser. Или же у Вас в проекте много веток и Вам хотелось бы более наглядно увидеть историю файла или сравнить разные версии. Вот плагин который поможет: versiontree.sourceforge.net
(пришлось самому заняться поддержкой, чтобы сделать версию для Eclipse 3.4 Ganymede)