Posts tagged ‘Mercurial’

One Thing that Git Does Better: Rebranching

2013-05-04 0:06

Much can be said about similarities between two popular, distributed version control systems: Git and Mercurial. For the most part, choosing between them can be a matter of taste. And because Git seems to have considerably more proponents in the Cool Kids camp, it doesn’t necessarily follow it’s a better option.

But I have found at least one specific and common scenario where Git clearly outshines Hg. Suppose you have coded yourself into a dead end: the feature you planned doesn’t pan out the way you wanted it; or you have some compatibility issues you cannot easily resolve; or you just need to escape the refactoring bathtub.

Rebranching in Git (start)

In any case, you just want to step back a few commits and pretend nothing happened, for now. The mishap might be useful later, though, so it’d be nice if we left it marked for the future.

In Git, this is easily done. You would start by creating a new branch that points to your dead end:

  1. $ git checkout my_feature
  2. $ git branch __my_feature__dead_end__

Afterwards, both my_feature and __my_feature__dead_end__ refer to the same, head commit. We would then move the former a little back, sticking it to one of the earlier hashes. Let’s find a suitable target:

  1. $ git log
  2. commit 130fe41a3a0587a48c1ef8797030ae2e682c6fb4
  3. Author: John Doe <john.doe@example.com>
  4. Date:   Fri May 3 21:39:32 2013 +0200
  5.  
  6.     I don't like this adventure. Not one bit.
  7.  
  8. commit f834a10d199f5c23fa14ed0ebfcf89226d9c21a1
  9. Author: John Doe <john.doe@example.com>
  10. Date:   Fri May 3 21:25:46 2013 +0200
  11.  
  12.     Let's try this, maybe...
  13.  
  14. commit 9d877d32f3a08f416615f9a051ad3985e6e4d2ad
  15. Author: John Doe <john.doe@example.com>
  16. Date:   Fri May 3 21:18:57 2013 +0200
  17.  
  18.     Shiny!
  19. $ git checkout 9d877
  20. Note: checking out '9d877'.
  21. # trimmed for brevity

If it looks right, we can reset the my_feature branch so it points to this specific commit:

  1. $ git reset --hard 9d877

Our final situation would then looks like this:

Rebranching in Git (end)

which is exactly what we wanted. Note how any further commits starting from the referent of my_feature would fork at that point, diverging from development line which has lead us into dead end.

Why the same thing is not so easily done in Mercurial?… In general, this is mostly because of its one fundamental design decision: every commit belongs to one branch, forever and for always. Branch designation is actually part of the changeset’s metadata, just like the commit message or diff. Moving things around – like we did above – is therefore equivalent to changing history and requires tools that are capable of doing so, such as hg strip.

Tags: , , ,
Author: Xion, posted under Programming » 5 comments

git outgoing

2012-11-20 12:05

Now that I don’t use Mercurial at work anymore, I’ve found that despite its shortcomings (hg status taking 10+ seconds?!) it has some few nice features. One of those is hg outgoing, which shows you which changesets you are going to send to remote repo in your next push. A quick glance at this list will typically ensure that everything is in order, or allow to amend some commits before making them public.

In Git you can do the similar by applying a filter to git log:

  1. $ git log origin/master..

But while origin is most often the remote you want to compare against, the master branch is typically not the one where most of development takes place. So if we want to create a git outgoing command, we would rather check what the current branch is and compare it with its remotely tracked equivalent:

  1. #!/bin/sh
  2. BRANCH=$(git name-rev HEAD 2>/dev/null | awk "{ print \$2 }")
  3. git log origin/$BRANCH..

Simply naming this script git-outgoing and making it executable somewhere within your $PATH (e.g. /usr/bin) will make the git outgoing command available:

  1. $ git outgoing
  2. commit 8c96c21c420dd10a34441cbd7d4c6904a6077716
  3. Author: Karol Kuczmarski <karol.kuczmarski@gmail.com>
  4. Date:   Tue Nov 20 11:51:44 2012 +0100
  5.  
  6.     Add .gitignore
  7.  
  8. commit 8a51a4f39b383c9dff64532403ab3922bc2ae13c
  9. Author: Karol Kuczmarski <karol.kuczmarski@gmail.com>
  10. Date:   Tue Nov 20 11:50:01 2012 +0100
  11.  
  12.     Comments in install script

There are few untold assumptions here, like the fact that branch names must match on both local and remote repo. If you find yourself breaking those, then you’re probably better to just use git log directly.

Tags: , ,
Author: Xion, posted under Programming » 3 comments

Coded4: Time-based Statistics for Git/Hg Repos

2011-12-24 16:23

As the ubiquitous spirit of laziness relaxation permeates the holiday season, a will to do any serious and productive coding seems appallingly low. Instead of fighting it, I went along and tried to write something just for pure fun.

And guess what: it worked pretty well. Well enough, in fact, that the result seems to be worthy of public exposure – which I’m hereby doing. Behold the coded4 project:

  1. $ git clone git@github.com:jquery/jquery
  2. $ coded4 jquery

  1. name                   commits time        
  2. -------------------------------------------
  3. John Resig             1211    5d 09:11:59
  4. jeresig                503     2d 07:50:02
  5. Jörn Zaefferer         309     1d 09:05:53
  6. Brandon Aaron          247     1d 01:34:29
  7. Dave Methvin           235     22:17:27    
  8. jaubourg               221     22:22:31    
  9. timmywil               221     23:00:56    
  10. Ariel Flesler          200     22:10:46    
  11.  
  12. ...

What exactly is this thing? It’s a “time sheet” for the marvelous jQuery project, reconstructed from commit timestamps in its Git repository. coded4 created this result by analyzing repo’s history, grouping changesets by contributors, and running some heuristics to approximate timespans of their coding sessions.

And of course, this can be done for any Git (or Hg) repository. Pretty neat for a mere *pops up shell and types coded4 .* 3 hours of casual coding, eh?

Terminologia rozproszonych systemów kontroli wersji

2011-06-06 19:31

W ostatnich latach rozproszone systemy kontroli wersji (w skrócie DVCS) stały się popularne, zwłaszcza w środowiskach związanych z open source. Warto je jednak znać nie tylko wtedy, gdy pracujemy nad projektami z otwartym źródłem. Jak bowiem pisałem wcześniej, mogą być one przydatne chociażby do małych jednoosobowych projektów. Ponadto bywają nierzadko używane w większych oraz mniejszych firmach. Ogólnie mamy więc duże szanse, aby prędzej lub później zetknąć się z takimi systemami.
Ten post jest adresowany przede wszystkim do osób, które nie miały wcześniej dłuższej styczności rozproszonymi systemami kontroli wersji. Ma on na celu wyjaśnienie wielu spośród tych tajemniczo brzmiących słówek, na jakie nieustannie można się natknąć, gdy pracujemy z DVCS-ami. Istnieje oczywiście szansa, że bardziej zaawansowani użytkownicy również wyciągną nowe wiadomości z lektury (albo chociaż przejrzenia) niniejszej notki. A jeśli nawet nie, to powtórzenie znanej sobie wiedzy na pewno im nie zaszkodzi ;)

Tags: , ,
Author: Xion, posted under Applications, Programming » 3 comments

Rozproszone systemy kontroli wersji

2010-10-20 23:10

Z systemami kontroli wersji (w skrócie VCS) zetknął się każdy programista i dla niemal wszystkich jest to oczywiste narzędzie pracy. Dla wielu jednak wciąż jeszcze kojarzą się one z jednym, centralnym miejscem zawierającym zawierającym bazę kodu projektu (czyli repozytorium) oraz z licznymi kopiami roboczymi, nad którymi pracują programiści. Kiedy zaś chcą połączyć swoje zmiany, wówczas wykonują tylko operację znaną jako commit.

Tak jest w systemach typu CVS czy Subversion, ale obecnie sporą popularność zyskały też inne, działające na nieco innej zasadzie. Nazywają się one rozproszonymi (distributed version control system – DVCS) i zgodnie z tym określeniem ich główną cechą jest brak wydzielonego, centralnego repozytorium. Zamiast tego może być ich dowolna ilość, która w rzeczywistych projektach może łatwo urosnąć do setek, a nawet tysięcy. Najczęściej bowiem swoje własne repozytorium ma na przykład… każdy pracujący nad projektem programista.
Obłęd? Niezupełnie. Wszystko opiera się bowiem na operacji synchronizacji dwóch repozytoriów, którą nazywa się – w zależności od punktu widzenia – push lub pull. Push oznacza wprowadzenie poprawek z naszego repozytorium do innego, zaś pull oznacza ściągnięcie zmian z innego repozytorium do własnego. Jak nietrudno zauważyć, operacja ta jest symetryczna. I chociaż techniczne wszystkie repozytoria są równoważne, w praktyce jedno z nich jest zwykle bazą projektu, zawierającą jego “autorytatywną” wersję. Ponadto z każdym repozytorium można też pracować “normalnie”, tj. przy pomocy znanych i lubianych operacji commit i update.


Działanie rozproszonych systemów kontroli wersji

Po co taka zmiana? Przydaje się ona zwłaszcza w dwóch sytuacjach:

  • Dla projektów typu open source umożliwia względnie niezależne opracowywanie poprawek do projektów. W tym celu wystarczy sklonować główne repozytorium, a następnie w spokoju pracować nad uzyskanym kodem, korzystając z jego kopii. Chcąc następie uczynić zmiany obowiązującymi, możemy wykonać push – ale tylko wtedy, jeśli mamy do tego prawa. Jeśli nie, możliwe jest stworzenie łatki (patch), zawierającej nasze modyfikacje i przekazania jej osobie zarządzającej projektem. Ta zaś może – zapewne po przetestowaniu zmian na własnej kopii repozytorium – wprowadzić je wreszcie do bazy kodu. Podobny akceptowania poprawek występował w projektach open source już od dawna, ale dopiero rozproszone systemy kontroli wsparły go od strony technicznej.
  • Jeśli pracujemy wyłącznie lokalnie nad własnymi projektami, możemy stworzyć sobie takież repozytorium, które będzie przy tym jedynym. Nie synchronizujemy wtedy zmian z żadnym innym repozytorium, ale wciąż możemy korzystać ze standardowych funkcjonalności systemów kontroli wersji.

W średniej skali (takiej, jak przedstawiona na obrazku powyżej) systemy rozproszone sprawdzają się natomiast nieco gorzej – zwłaszcza, gdy częstotliwość zmian jest duża. Wówczas często zachodzi potrzeba łączenia (merge) różnych ścieżek tworzenia aplikacji.

Tym niemniej warto się zainteresować tego rodzaju systemami kontroli wersji, by przekonać się, że poza Subversion też coś istnieje :) Przykładami rozproszonych VCS-ów są np. Mercurcial i Git.

Tags: , , , ,
Author: Xion, posted under Applications, Programming » 3 comments
 


© 2017 Karol Kuczmarski "Xion". Layout by Urszulka. Powered by WordPress with QuickLaTeX.com.