Задание 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 - мы получим хэлпы.
