Как стать автором
Обновить
  • по релевантности
  • по времени
  • по рейтингу

Mercurial: как увидеть лес за деревьями?

Разработка веб-сайтов *
Mercurial (он же Hg) — весьма приятная распределенная система контроля версий (distributed VCS). Среди удобств DVCS вообще и Hg в частности можно особо выделить высокую гибкость. Репозиторий может называться как угодно, копироваться куда угодно, коммититься в продакшн по произвольным цепочкам (скажем, через QA или напрямую) и так далее.

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

Если два репозитория вложить один в другой, Mercurial будет рассматривать их изолированно. Команды, адресуемые внешнему репозиторию, не распространяются на вложенный. Но как же управляться с проектом, если он раздроблен на изолированные фрагменты — этакие пузырьки, один в другом? Или, другими словами, как нам за деревьями (репозиториями) увидеть лес (проект) и работать на его уровне? От мучений нас избавит ForestExtension — расширение для Mercurial. Этот Forest добавляет несколько команд, идентичных базовым, но учитывающих вложенность репозиториев.
Дальше в лес
Всего голосов 13: ↑13 и ↓0 +13
Просмотры 2.2K
Комментарии 4

DVCS and DAGs

Разработка веб-сайтов *
Перевод
Перевод статьи Эрика Синка (Eric Sink) — DVCS and DAGs (Part 1 and Part 2).

Прим. переводчика: В этой статье я буду ис­поль­зо­вать ори­гиналь­ные анг­ло­языч­ные сокращения DVCS и DAG для обозначения расп­ре­делён­ных систем контроля версий (Distributed Version Control System — DVCS) и нап­равлен­ных ацикличных графов (Directed Acyclic Graph — DAG).
Читать дальше →
Всего голосов 33: ↑31 и ↓2 +29
Просмотры 3.7K
Комментарии 18

ХХ полезных советов для пользователей Git среднего уровня. Часть 1

Git *
Вообще-то изначально я планировал перевести статью Энди Джеффриса (Andy Jeffries) 25 Tips for Intermediate Git Users, но в процессе я отбросил бестолковые, общеизвестные или самые простые советы вроде «настройте первым делом user.name и user.email», которые явно не подходят людям, уже более-менее плотно знакомым с Git.
Взамен я дополню статью моментами из личной практики («Своя практика»! Звучит здорово, будто я частный врач или адвокат! :-] )

Читать дальше →
Всего голосов 75: ↑70 и ↓5 +65
Просмотры 25K
Комментарии 32

ХХ полезных советов для пользователей Git среднего уровня. Часть 2

Git *
Это продолжение статьи ХХ полезных советов для пользователей Git среднего уровня

Про reset, незапланированно снова про альясы, про замечательный filter-branch, про мерджи и разрешение конфликтов с помощью rerere, про rebase (интерактивный и не очень) и, в завершение, про обслуживание своей гитницы.

Читать дальше →
Всего голосов 38: ↑32 и ↓6 +26
Просмотры 22K
Комментарии 35

GIT, HG и прочие DVCS vs VSS, SVN и прочих SVCS: в первых деревья ортогональны, во вторых — смешаны!

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

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

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

Читать дальше →
Всего голосов 11: ↑2 и ↓9 -7
Просмотры 3.1K
Комментарии 23

Вышли Mercurial 1.5 и TortoiseHg 1.0

Системы управления версиями *
Вышла новая версия распределённой системы управления версиями Mercurial и user-friendly клиента для этой системы — TortoiseHg.

Список изменений под катом
Всего голосов 50: ↑44 и ↓6 +38
Просмотры 2.5K
Комментарии 39

Два слова из трёх букв: TMS и VCS

Разработка систем связи *
За последний месяц мне поступило три звонка, в которых звучали эти загадочные слова, и я был вынужден объяснять, как оно работает. Я глубоко убежден, что знаниями нужно делиться, — это верное средство от деградации. Потому, в меру своего понимания попробую объяснить широкой общественности, что же они значат. Итак, далее речь пойдёт о трёх устройствах TANDBERG для обеспечения видеосвязи: TMS, VCS Control и VCS ExpressWay.
Читать дальше →
Всего голосов 4: ↑3 и ↓1 +2
Просмотры 8K
Комментарии 6

Файл⇨строка или активность работы над файлом

Системы управления версиями *
Большинство разработчиков знакома с таким продуктом, как визуализатор code_swarm (на google code). Как минимум каждый третий наверняка выгружал для него лог и создавал видео, которое визуализирует процесс разработки приложения, в котором видно активность программистов. Ну и конечно каждый второй видел видео подобного рода. Практически все эти видео делались на срезе отношения программист⇨файл.
В этой статье будет описан процесс формирования лога в срезе отношения файл⇨строка, то есть с генерированное видео будет демонстрировать активность работы над файлом.

Кому это интересно под прошу под кат.
В статье будет использованы:
  • Git — VCS
  • code_swarm — визуализатор истории репозиториев.
  • gource — визуализатор истории репозиториев.
  • Эмулятор среды linux в Windows или UNIX OS (с git уже идет для win эмулятор msysgit)
  • MEncoder — свободный кодировщик видео
  • ffmpeg — программа для конвертации видео с использованием различных кодеков.
Далее...
Всего голосов 44: ↑42 и ↓2 +40
Просмотры 1.9K
Комментарии 12

Как начать работать с GitHub: быстрый старт

Git *


Распределенные системы контроля версий (DVCS) постепенно замещают собой централизованные. Если вы еще не используете одну из них — самое время попробовать.

В статье я постараюсь показать, как можно быстро начать экспериментировать с git, используя сайт github.com.

В статье не будут рассмотрены различия между разными DVCS. Также не будет детально рассматриваться работа с git, по этой теме есть множество хороших источников, которые я приведу в конце статьи.
Читать дальше →
Всего голосов 182: ↑165 и ↓17 +148
Просмотры 1.2M
Комментарии 51

Хабрахабр не торт. Хабрахабр сыр. 

Habr
Осеннее обновление Хабрахабра, к нашему общему сожалению, обладает множеством убедительных признаков сырого кода (прочтите их и дополните в комментариях, если я чего-то не заметил или пропустил):

Читать дальше →
Всего голосов 350: ↑316 и ↓34 +282
Просмотры 1K
Комментарии 119

Ограничение доступа к репозиториям

Системы управления версиями *
Из песочницы
Чтобы управлять доступом можно использовать различные решения gitosys, gitolite, mercurial-server, но эти решения работают через SSH, что не всегда удобно (должен быть ключ). В добавок не хватает гибкости у подобных решений.

Основные требования:
  • доступ по логину/паролю (HTTPS)
  • контроль прав на чтение/запись
  • публичный/приватный репозиторий
  • управления всем через веб интерфейс
  • все данные (информация о проекте и пользователях) должны храниться в базе (MySQL)


Для решения этой задачи сделал следующую систему…

Читать дальше →
Всего голосов 22: ↑19 и ↓3 +16
Просмотры 3.9K
Комментарии 9

Перенос истории из CVS/PCVS/VSS/ClearCase/StarTeam/MKS в SVN

Системы управления версиями *
Из песочницы
Доброго времени суток!

Данная статья посвящена одной небольшой задачке – переносу репозитория вместе со всей историей с одной системы управления версиями в другую, а точнее – в SVN. Речь пойдёт об использовании бесплатной утилиты Importer for SVN от Palarion, с помощью которой можно мигрировать с CVS / PCVS / VSS / ClearCase / StarTeam / MKS на SVN, не потеряв при этом журнала изменений кода. В моём случае потребовалось перенести проекты из Borland StarTeam.

Почему было сказано «нет» StarTeam и «да» SVN? Сначала думал пропустить данный абзац во избежание холиваров. Но, пожалуй, без этого статья была бы лишена, скажем так, области определения. В моём случае отказаться от StarTeam вынудил уход человека, его внедрившего и администрировавшего. Пара дней безуспешных попыток заставить работать сервис под другой учётной записью породили мысль о том, что задача восстановления репозиториев из бэкапов станет ещё большим вызовом. Конечно, радиус кривизны рук можно было значительно увеличить спустя какое-то время. Но оно нам надо, спрашивается, когда есть бесплатный, до безобразия лёгкий в установке и поддержке SVN? Тем более что у меня было предостаточно опыта его использования на предыдущих местах работы, а все два с половиной разработчика находятся в одной комнате.

Одно препятствие – жаль было терять историю изменений. Сначала думали залить в SVN текущие версии, а историю смотреть в StarTeam, переведя его предварительно в read-only. Но, как говорится, это не наш метод. И непродолжительный гуглопоиск навёл на выше в суе помянутый Palarion Importer for SVN.

Теперь непосредственно к сути...
Всего голосов 19: ↑16 и ↓3 +13
Просмотры 2.6K
Комментарии 9

Пожаробезопасность в системах управления версиями

Системы управления версиями *
image
На сегодняшний день существуют два типа систем управления версиями: клиент-серверный и распределенный. Но несмотря на огромное различие между ними мы все-равно продолжаем использовать центральный сервер для синхронизации работы между участниками команды.
А что будет если в один прекрасный день центральный сервер сгорит?
Давайте это обсудим
Читать дальше →
Всего голосов 9: ↑4 и ↓5 -1
Просмотры 4K
Комментарии 11

FeatureBranch

Git *
Перевод
С распространением распределенных систем управления версиями (DVCS), таких как Git и Mercurial, я все чаще вижу дискуссии на тему правильного использования ветвления(брэнч) и слияния(мердж), и о том, как это укладывается в идею непрерывной интеграции (CI). В данном вопросе есть определенная неясность, особенно когда речь заходит о feature branching (ветвь на функциональность) и ее соответствие идеям CI.

Простой (изолированный) Feature Branch

Основная идея feature branch заключается в создании нового брэнча, когда вы начинаете работать над какой-то функциональностью. В DVCS вы делаете это в своем собственном репозитории, но те же принципы работают и в централизованных VCS.

Я проиллюстрирую свои мысли следующим рядом диаграмм. В них основная линия разработки (trunk) отмечена синим, и двое разработчиков, отмеченные зеленым и фиолетовым (Reverend Green и Professor Plum).

image

Читать дальше →
Всего голосов 40: ↑38 и ↓2 +36
Просмотры 19K
Комментарии 27

Как развернуть систему контроля версий (VCS) без командной строки

Блог компании Арнион Разработка веб-сайтов *Mercurial *
Recovery mode

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

Естественно, поиски были начаты с изучения Хабра — и привели к неожиданному результату. Несмотря на то, что системы контроля версий появились ещё в 1986 году, большинство туториалов по работе с современными системами контроля версий оказались неполными и сильно завязанными на работу с командной строкой.

Мы ничего не имеем против командной строки в целом, но в нашей небольшой команде разработчиков (4 человека) фанатов работы с командной строкой нет :).

Почему мы считаем, что работа с командной строкой неэффективна?

  1. Трата времени на ввод данных. Набивать команды намного дольше, чем кликать мышкой.
  2. Трата времени на обучение. Изучение нового синтаксиса в эпоху понятных интерфейсов однозначно дольше, чем обучение графическому интерфейсу.
  3. Вероятность ошибки. Ошибиться при вводе данных через командную строку легче (человеческий фактор никто не отменял).
  4. Нарушение принципов автоматизации. Возможно, это самый главный пункт. Компьютер создан для ускорения работы и замене человека при выполнении рутинных операций. В случае с командной строкой мы всегда работаем вручную, по сути, приходится каждый раз писать один и тот же программный код (пусть и примитивный).

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

  1. Будет пошаговой инструкций (по ней же будут работать наши программисты).
  2. Будет работать от начала и до конца (то есть по ней вы получите небольшой, но законченный результат — работающую распределенную систему контроля версий).
  3. Будет работать с использованием только графических интерфейсов (причины см. выше).
Читать дальше →
Всего голосов 45: ↑11 и ↓34 -23
Просмотры 24K
Комментарии 26

Дружим Git с Putty

Разработка веб-сайтов *Git *Системы управления версиями *
Tutorial
Disclaimer
Предварительно делал поиск по хабру с надеждой на подобный пост, смог найти только вот этот пост, в котором вся работа производятся через TortoiseGit.

Но это не наш метод. По той причине, что в этом случае все наши IDE не смогут сами сделать Push на сервер. Да и через Git Bash ничего не получится сделать на сервере.
почему мне нужно использовать Git в связке с Putty?
Так уж получилось, что я активно использую Putty с настроенными ключами для доступа к серверам. Ключей у меня не один. Git-репозитариев тоже не один.
Конечно же, можно нагенерить OpenSSH ключей для Git-а и разрулить их через ~/.ssh/config, но это получается двойная работа – поддержка ключей в Putty и отдельная поддержка для Git.



Итак, представим, что у нас девственно чистая система, в которой нет ни Putty, ни msysgit. Приступим к настройке нашего рабочего окружения.

Установка Putty


Качаем, устанавливаем, генерим и настраиваем ключ c Pagent (инструкция, ?).

Добавляем ключ на git-сервер


Копируем публичный OpenSSH ключ из Putty-ключа
Запускаем Putty key Generator
Открываем (кнопка «Load») наш PPK-ключ
Копируем весь текст из блока «Key»

Открываем страницу с SSH ключами и добавляем из буфера наш ключ
В картинках (на примере GitHub)






Создаём и сохраняем в Putty профиль «git@github.com» и проверяем, что удаётся зайти по ключу – должна открыться и сразу закрыться консоль.
В картинках





Устанавливаем и настраиваем msysgit

Дайте весь текст!
Всего голосов 39: ↑27 и ↓12 +15
Просмотры 42K
Комментарии 23

Системы контроля версий: Fossil, часть I

Системы управления версиями *
Tutorial
Приветствую вас, коллеги!

Относительно недавно здесь публиковался опрос по используемым системам контроля версий. Как и ожидалось, с большим отрывом победил Git, а Fossil даже не был включен в список, только в комментариях пару раз промелькнул. Поиск по Хабру показал, что здесь о Fossil практически ничего не писали. Поэтому я и решил опубликовать эту статью — тем более, что русскоязычная информация о Fossil крайне скудна и однообразна.
Читать дальше →
Всего голосов 50: ↑45 и ↓5 +40
Просмотры 35K
Комментарии 77

Системы контроля версий: Fossil, часть II

Системы управления версиями *
Tutorial
Продолжаем разговор о Fossil.

В первой части мы познакомились с использованием Fossil в однопользовательском режиме на одном рабочем месте. Следующий шаг — перенос репозитория на другой компьютер — с работы на домашний, или на ноутбук, который мы берем с собой в поездку. Самый простой вариант — это просто скопировать репозиторий, благо это всего один файл, на новое рабочее место. Можно так и сделать, но самое простое решение не всегда самое лучшее, есть вероятность, что возникнут небольшие проблемы.
Читать дальше →
Всего голосов 21: ↑18 и ↓3 +15
Просмотры 13K
Комментарии 8

Почему я не испытываю неприязни к Git: скрытая целостность

Блог компании Positive Technologies Разработка веб-сайтов *Программирование *Git *
Перевод


Предлагаю вашему вниманию перевод небольшой статьи из блога Armin Ronacher — автора Flask, Jinja2 и много чего еще. На этот раз он поделится своими мыслями о Git — распределенной системе управления версиями файлов.

Git для меня интересная тема. Впервые я попробовал использовать Git, когда там не было вообще никакой системы команд, а Cogito считался многообещающим проектом. Не могу сказать, что мне это понравилось, в то время я в основном пользовался SVN, и он полностью решал все мои задачи. Вскоре я познакомился с Mercurial, и это была любовь с первого взгляда, положившая начало долгому и позитивному опыту использования этой VCS (version control system), которая получила в моем лице преданного сторонника. Только в 2008 году я перешел на Git, и мне потребовалось несколько попыток, прежде чем я понял, что пора переносить на него мои репозитории.
Читать дальше →
Всего голосов 71: ↑63 и ↓8 +55
Просмотры 41K
Комментарии 83