Strona używa cookies (ciasteczek). Dowiedz się więcej o celu ich używania i zmianach ustawień. Korzystając ze strony wyrażasz zgodę na używanie cookies, zgodnie z aktualnymi ustawieniami przeglądarki.    X

O tym jak efektywnie pracować nad wieloma permutacjami w ramach jednego projektu, Czyli krótki poradnik DVCS, na przykładzie Mercurial. I

Zainspirowany niedawnym wpisem Meszuge (wpis zniknął więc nie podam linka), postanowiłem opisać narzędzie, bez którego nie może się obejść, żadem programista. Ale które może się przydać wszystkim, którzy pracują nad plikami tekstowymi, a chcą łatwego sposobu na "kopie zapasowe".

Systemy kontroli wersji (skrót to VCS - version control system) jako narzędzia rozwiązują konkretne problemy i w tych kategoriach powinniśmy je oceniać. Przyjmijmy na moment zmyślony scenariusz opisujący problem, które VCS próbują rozwiązać:

Problem

Mamy coś do napisania (nie ważne czy chodzi o magisterkę, artykuł w Latexie dla gazety, czy kod źródłowy programu), praca objętościowo będzie w miarę duża (5+ stron A4), oraz na pewno będziemy nad nią pracować iteracyjnie (od ogólnego pomysłu do np. 15tej ostatecznie wersji), poprawiając lub rozbudowując różne partie tekstu, często po paru dniach od napisania oryginału. Więc chcemy mieć możliwość wycofania ostatnio wprowadzonych zmian.

Pierwsze rozwiązanie

Oczywistym wyborem jest edytor tekstu z opcją Cofnij, i to taką bez ograniczeń.

Ale co zrobić gdy chcemy wycofać zmiany z wczorajszego wieczora?

Drugie podejście

W takim razie możemy zdecydować się na kompresowanie i archiwizowanie całego tekstu co dziennie po skończonej pracy.

Dodatkowo uzyskaliśmy zabezpieczenie przed przypadkowym usunięciem pliku (lub gdy projekt składa się z kilku plików) oraz zmian w strukturze projektu.

No dobrze a co gdy padnie nam dysk? W przypadku pracy dla gazetki szkolnej szkód wielkich nie będzie, ale co z pracą magisterską gdy dysk spłoną na 2 miesiące przed terminem obrony?

Do trzech razy sztuka?

W takim razie dochodzi nam archiwizacja na dysk zewnętrzny (płytki CD, pendrivy też będą spełniały tą rolę).

No dobra ale jak poradzić sobie z bałaganem gdy nad projektem pracujemy już 13 dzień. Jak nie pogubić się w tych wszystkich kopiach zapasowych?

Jeszcze raz o tym co chcemy osiągnąć

Bogatsi o te doświadczenia możemy teraz doszlifować nasze wymagania. Potrzebujemy:
1) Mieć możliwość cofania zmian, i to na poziomie poszczególnych zdań, a nie tylko plików.
2) Mieć możliwość przechowywania struktury plików (gdy pracujemy nad kilkoma).
3) Mieć możliwość przechowywania kopi zapasowej całej "historii" projektu na zewnętrznym komputerze.
4) Narzędzie ma być maksymalnie proste oraz szybkie w obsłudze.
5) Narzędzie ma być darmowe (ok, jak kogoś stać to może wybrzydzać).
6) Chcemy mieć możliwość pracowania nad projektem w kilka osób, tak, że by 2 lub więcej osób mogło naraz edytować jeden plik.
7) Chcemy mieć możliwość tworzenia wariantów, które mogły by później być włączone do głównej wersji projektu jeśli konkretny wariant się nam spodoba.

Rozwiązanie

Czas odsłonić nasze wymarzone narzędzie:
Rozproszone systemy kontroli wersji.
1) Zmiany są zachowywanie jak różnica pomiędzy ostatnią wersją pliku a jego obecną wersją, gdy tego sobie zażyczymy. Więc mogą one objąć, zarówno zmiany połowy pliku jak i pojedynczego byka ortograficznego.
2) Struktura plików jest dokładnie zachowywana, a gdy jakichś plików nie chcemy przechowywać to też nie musimy. Oznacz to też, że zmiany możemy cofnąć wybiórczo dla poszczególnych plików. Dla wygody zaś zmiany są zapamiętywane dla całego projektu, jedną czynnością.
3) "Historię" projektu możemy umieścić na innym komputerze oraz na bezpłatnym hostingu (co znacznie obniża szansę utraty ważnej pracy). Ale również na drugim komputerze i o ile oba są podłączone do internetu w danej chwili to możemy uaktualnić zmiany wprowadzone na drugim jedną prostą czynnością. (Koniec z szuflowaniem pendrivem w tę i we wte pomiędzy laptopem i stacjonarką). A gdy nie są to i tak zewnętrzny hosting załatwi ten problem.
4) Nie tylko narzędzia są proste ale również istnieją świetne graficzne nakładki, tak, że wszystko można sobie wy-klikać!
5) Pełen wybór na wszystkie platformy.
6) Dzięki 3) na raz mogą pracować różne osoby, nawet na komputerach ustawionych po przeciwnej stronie globu. A dzięki temu, że zmiany są przechowywane jako różnice, narzędzia są sobie wstanie poradzić nawet wtedy gdy kilka zmian odnosi się do jednego pliku, a gdy zmiany odnoszą się do tego samego tekstu, można zdecydować która wersja zostanie zachowana.
7) A gdybyśmy chcieli pracować nad kilkoma wariantami tekstu (np. kilkoma wersjami wstępu?), nic prostszego. Przeskakiwanie z jednej wersji na drugą też nie sprawi problemu. A najlepszy wariant będzie mógł być połączony z roboczą wersją w dowolnym momencie w przyszłości, nawet gdy zmiany w wersji roboczej będą ogromne.

Chcemy więcej!

Brzmi jak PR? Chcecie przykładów?
Musicie tylko poczekać do następnego wpisu, w którym przedstawię Mercurial, TortoiseHg, oraz hosting bitbucket, wszystko działające pod Windowsem.

Co można umieścić w VCS?

Nie ma żadnych ograniczeń co do rodzajów plików, którymi VCS może się opiekować. Choć gdy VCS nie zna struktury pliku wtedy próba połączenia kilku wariantów pliku (np. z muzyką) da wynik daleki od oczekiwań.
Jak słusznie zauważył Ave5 powstał ciekawy projekt dla GIMPa, który sprawia, że będzie można przechowywać zmiany dla poszczególnych operacji graficznych wykonanych w danym pliku!

Podziękowania dla @Fazid za wyłapanie drobnego błędu z użytymi skrótami. (CVS to nazwa konkretnego programu, VCS całej ich kategorii).

Następna część! 

Komentarze

0 nowych
Ave5   8 #1 04.09.2011 12:17

Dobry wpis. Mogłeś też wspomnieć, że system kontroli wersji istnieje już do GIMPa :)

djfoxer   17 #2 04.09.2011 14:17

Przejrzyście przedstawione.
Może jakieś porównanie CVS vs SVN?

przemo_li   11 #3 04.09.2011 14:52

Dla początkującego Mercurial lepszy, no i ma dość dobre GUI!

PS CVS jako program to przeżytek... Nazwy używałem jako określenia dla całej kategorii. DCVS to rozproszone systemy wersji, bez głównego serwera, a z łatwymi i prostymi gałęziami, ale o tym w następnej części.

DannyPL   5 #4 04.09.2011 21:10

@przemo_li
W tytule: "ktrótki" i "Mericurial" do poprawy. Na przyszłość polecam wkleić cały tekst do jakiegoś edytora ze sprawdzaniem pisowni.

  #5 04.09.2011 21:36
drobok   13 #6 04.09.2011 22:33

znikną / drógim :)

djfoxer   17 #7 04.09.2011 23:23

Nie zrozumieliśmy się :) Skoro zacząłeś od CVS (jako technologii) liczyłem, że coś powiesz o jego następcy SVN i jakieś porównanie zrobisz, czy coś.

Fazid   3 #8 05.09.2011 02:11

Nieporozumienie wynikło z błędnej terminologii użytej w notce. CVS (Concurent Version System) to konkretna implementacja systemu VCS (Version Controll System). Mówimy tutaj raczej o DVCS (Disturbed/Decentralized Version Controll System) a nie o DCVS (Distributed Concurrent Versions System, który faktycznie istnieje, ale znów - jest konkretną implementacją).

Więc Mercurial to VCS/DVCS i taki skrót powinien być w notce używany.

Samego wpisu jestem w sumie ciekawy, bo nie stosowałem nigdy systemów kontroli wersji do dokumentów o złożonym formacie (np. doc), zazwyczaj jedynie czyste pliki tekstowe. Może być więc interesujące, jeśli autor pokusi się o zaprezentowanie działania systemu na tego typu plikach (np. realizacja diffa czy eliminacji konfliktów na przykładzie większego dokumentu doc z bogatym formatowaniem).

przemo_li   11 #9 05.09.2011 06:43

@Fazid
Dzięki za poprawną terminologię.

@djfoxer
Nie znam się ani na subversion ani na cvs. Moje informacje o nich są za stare. Poza tym git i hg (potoczna nazwa Mercurial) dawno wyparły svn i cvs w miejscach w których mógł bym się z nimi zetknąć. Moim osobistym faworytem jest Git, ale jako, że nie znam dobrego GUI pod Wingrozę, to pokażę hg.

tomasz154   2 #10 05.09.2011 11:38

@przemo_li
1. Nie TortoiseHq a TortoiseHg.
2. TortoiseGit? Mi odpowiada.

przemo_li   11 #11 05.09.2011 12:21

@tomasz154
Literówka poprawiona. A TortoiseGit sprawdzę, ale TortoiseHg ma ładniejszą stronę domową, dokumentacja też wydaje się być lepsza, a następny wpis ma być dla nietechnicznych.

tomasz154   2 #12 05.09.2011 12:50

Strona domowa to nie wszystko. Co do dokumentacji, to help TGit-a jest dość dobry.

TortoiseGit jest forkiem TortoiseSVN, który chyba wywodzi się z TortoiseCVS. Sprawdzona technologia ;-)
TortoiseHg to niezależny projekt, który dzieli z poprzednimi idee i nazwę.

Wadą TortoiseGit jest, że istnieje tylko dla Windows,
A TortoiseHg jest wieloplatformowy (napisany w Pythonie podobnie jak sam Mercurial).

Cóż. Powodzenia, mam nadzieję, że komuś się to przyda, ale obawiam się, że nietechniczni będą jednak woleli trzymać pliki na pulpicie i kopiować na dyskietki ;-) Celowałbym raczej w początkujących programistów.

ziggurad   11 #13 05.09.2011 17:30

Używałem w pracy svn'a, chętnie przeczytam dalej ;)

silvestr   4 #14 05.09.2011 18:27

Też korzystam z svn w pracy. Nie znam innych, ale to jest wygodne narzędzie :)

przemo_li   11 #15 05.09.2011 18:35

@ziggurad @silvestr
Gdzie ja będę takie stare wygi jak wy, uczył podstaw systemów kontroli wersji, lub dlaczego warto pracę magisterską w tym trzymać? ;) Teksty będą skierowane do początkujących oraz do osób które o takich programach w ogóle nie wiedziały.

Zulowski   8 #16 06.09.2011 00:09

Przydatny wpis, czekam na kolejne, właśnie biorę się za magisterkę po kilku miesiącach leniuchowania.

przemo_li   11 #17 06.09.2011 06:11

@Zulowski
W czym ją będziesz pisał?
Edytor tekstu jak MS OO, OO.org, Google Docs?
Latex, czy jakiś inny język znaczników?
(no i z jakiej dziedziny?)