Kodomo

Пользователь

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