Задание 2: Репозитории.
Содержание
Репозиторий
Репозиторий - это хранилище версий файлов.
Всем знакома ситуация с постоянными поправками в тексте курсовой
И если мы правим текст, а оказывается, что предыдущий вариент был явно лучше, чем этот...
В таких случаях, а также при работе в команде очень удобно пользоваться репозиторием.
Из чего он состоит?
А состоит он из двух частей:
1) то, за чем следит - это рабочая директория (текущее состояние);
2) и собственно из истории (предыдущие состояния).
Какие бывают репозитории?
CVS - самый первый репозиторий. Многие всё ещё ссылаются на него.
SVN - SVN и GIT борются за первенство по популярности.
GIT - близко к гениальному, но не удобно!
Mercurial - HG
Darcs - проще чем HG; ужасен; не годится совсем; никуда не растёт!
TortoiseHG
TortoiseHG - графический интерфейс для для системы контроля версий Mercurial.
Команды для работы с репозиторием в командной строке.
hg init - создать директорию с начальным наполнением.
hg add - указываем те файлы, за которыми следим. Например, hg add article.txt Если мы хотим, следить за всеми файлами в директории, пишем: hg add *.py.
hg commit - запомнить все изменения и записать их в репозитории.
Необходимо записывать следующим образом: hg commit -m "Added article".
Тогда он запомнит с введённым комментарием. Важно записывать с комментарием. В первый раз commit вас спросят кто вы, и попросят создать директорию.
hg mv article.txt article2.txt - переименовать файл в article2.txt
hg rm article.txt - перестать следить за файлом и удалить его.
hg diff article.py - покажет какие именно изменения вы сделали.Цитата:"Очень напоминает построчные вертикальные выравнивания."
hg st - выдаст следующего рода информацию: изменили то; слежу за теми файлами; сказали следить за теми,но не сохранили изменения; за теми сказали не следить.
hg update - сохранить в файле, с которым работаем последнюю версию изменений.
hg update -r1 - сохранить в файле изначальную версию.
hg update следует выполнять всегда после команд pull/push.
Обмен данными. Совместная работа
Представим, что у нас есть два персонажа: Alice и Bob. Им поручили сделать вместе работу. Alice начала работать в субботу и сделала три файла.Они так и будут называться:1,2 и 3. Bob же начал работать в воскресенье. И чтобы присоединиться к делу, и отталкиваться от работы, проделанной Alice, ему необходимо прописать следующую команду, чтобы перекопировать её файлы себе:
hg clone A - позволяет создавать идентичную копию существующей репозитории.
Под "А" понимаем путь к репозитории.
Путь к репозиторию может быть указан тремя различными способами:
1) указать непосредственно путь к файлу;
2) если репозиторий в WEB, то прописать URL;
3) использовать специальный путь, каким пользовались в данной работе:
ssh://user@server/~путь.
Bob поработал и всё, что он сделал решил отправить Alice. Для этого он "отпушил" изменения Alice:
hg push
A Alice, если хочет перекинуть себе изменения Boba, то должна прописать следующую команду:
hg pull Надо отметить, что pull/push меняют историю, а не директорию.
graph merge { fontsize=9.0 pencolor=white node [fontsize=9.0, width=0.3, height=0.2, shape=box, style=filled, fillcolor=lightsteelblue1] subgraph cluster_a1 { label="Alice" a1_3 -- a1_2 -- a1_1 -- a1_0 a1_3 [ label="3" ] a1_2 [ label="2" ] a1_1 [ label="1" ] a1_0 [ label="0" ] } subgraph cluster_b1 { label="Bob" b1_3 -- b1_2 -- b1_1 -- b1_0 b1_3 [ label="3" ] b1_2 [ label="2" ] b1_1 [ label="1" ] b1_0 [ label="0" ] } subgraph cluster_a2 { label="Alice" a2_4 -- a2_3 -- a2_2 -- a2_1 -- a2_0 a2_4 [ label="4" ] a2_3 [ label="3" ] a2_2 [ label="2" ] a2_1 [ label="1" ] a2_0 [ label="0" ] } subgraph cluster_b2 { label="Bob" b2_5 -- b2_3 -- b2_2 -- b2_1 -- b2_0 b2_5 [ label="5" ] b2_3 [ label="3" ] b2_2 [ label="2" ] b2_1 [ label="1" ] b2_0 [ label="0" ] } subgraph cluster_a3 { label="Alice, after pull" a3_4 -- a3_3 a3_5 -- a3_3 -- a3_2 -- a3_1 -- a3_0 a3_5 [ label="5" ] a3_4 [ label="4" ] a3_3 [ label="3" ] a3_2 [ label="2" ] a3_1 [ label="1" ] a3_0 [ label="0" ] } subgraph cluster_a4 { label="Alice, after merge" "changes" -- a4_4 -- a4_3 a4_5 -- a4_3 -- a4_2 -- a4_1 -- a4_0 "changes" -- a4_5 [style=dotted] a4_5 [ label="5" ] a4_4 [ label="4" ] a4_3 [ label="3" ] a4_2 [ label="2" ] a4_1 [ label="1" ] a4_0 [ label="0" ] } subgraph cluster_a5 { label="Alice, after merge & commit" a5_6 -- a5_4 -- a5_3 a5_6 -- a5_5 -- a5_3 -- a5_2 -- a5_1 -- a5_0 a5_6 [ label="6" ] a5_5 [ label="5" ] a5_4 [ label="4" ] a5_3 [ label="3" ] a5_2 [ label="2" ] a5_1 [ label="1" ] a5_0 [ label="0" ] } }
Допустим,что изменения у Alice под номером 4,а у Boba - под номером 5. Но теперь, им надо слить всё воедино, для чего Bob использует команду:
hg merge
И тогда, если их изменения касаются не одного и того же места в файле, то будет создана новая версия под номером 6.
Но если не всё так гладко, то говорят, что возник КОНФЛИКТ. Alice уже создала 4 версию днём, а Bob завершил свою работу вечером и его версию мы назовем версией 5. Он пытается произвести hg merge, но получает в результате весть о том, что автоматически объединить невозможно. Тогда ему придётся воспользоваться командой hg pull, то есть перекинуть себе изменения Alice.И потом уже провести hg merge и выбрать какие изменения оставить.
Команды hg pull, hg merge, commit, hg update можно записать с помощью одной команды hg fetch.
Прописав команду hg help - мы получим хэлпы.