Moved answers to text file instead of latex.

portfolio/revisioncontrol/.gitignore

-git.pdf

portfolio/revisioncontrol/git.tex

-\documentclass{article}
-
-\usepackage{url}
-\usepackage[dutch]{babel}
-\usepackage{listings}
-
-\title{Portfolio Informatica \\
-       Opdracht Revision Control - Git \\
-       Tadde\"us Kroes (6054129)}
-
-\begin{document}
-
-\maketitle
-
-\section{Mijn RCS van keuze}
-Ik heb gekozen voor het DRCS Git. Ik kies hiervoor omdat ik het zelf gebruik
-voor het werken aan groepsopdrachten voor de studie en ik het prettig vind
-werken. Ik heb in het verleden ook SVN gebruikt en ik heb gemerkt dat Git toch
-en aantal voordelen waarvan enkele zijn:
-\begin{itemize}
-\item Git is sneller, het werkt namelijk met een lokale repository. Je werkt dus
-allereerst vanuit je eigen harde schijf en pas na een definitieve wijziging
-`push' je je commits naar de server. Bij een CRCS als bijvoorbeeld SVN is er
-altijd internetverbinding nodig voor een commit waar dit bij Git dus alleen
-kan worden gebruikt om commits op een remote server te plaatsen (te `pushen') en
-en ze er weer vandaan te halen (te `fetchen'). Dit werkt erg prettig voor mij
-persoonlijk als ik op mijn laptop werk en geen beschikking over een
-internetverbinding heb. Ook bij de communicatie met de server is Git zeer snel,
-dit komt doordat het is ontwikkeld voor het werken aan de Linux-kernel waarbij
-snelheid en effici\"entie een must zijn.
-\item Door het gedecentraliseerde karakter laat Git toe dat ik met een bepaalde
-persoon een totaal andere versie kan delen dan met een andere persoon wat erg
-handig is als je met verschillende personen in meerdere werkgroepen zit.
-\end{itemize}
-Ik ga nu niet verdere in op alle voor- en nadelen van verschillende revision
-control systemen, want dat zou een paper op zich worden. Ik wil met bovenstaande
-slechts duidelijk maken waarom ik kies voor Git in deze opdracht.
-
-\section{Vragenlijst}
-In de opdracht staat een lijst met een aantal vragen en opdrachten. Deze zal ik
-hier met bijbehorende nummers proberen te beantwoorden.
-\begin{enumerate}
-\item Ik gebruik als working repository mijn eigen `uva'-repository van waaruit
-ik werk met medestudenten.
-\item
-\item
-\item
-\item
-\item
-\item
-\item
-\item
-\item
-\item
-\item
-\item
-\item
-\item
-\end{enumerate}
-
-\end{document}

portfolio/revisioncontrol/git.txt

+--- Mijn RCS van keuze ---
+
+Ik heb gekozen voor het DRCS Git. Ik kies hiervoor omdat ik het zelf gebruik
+voor het werken aan groepsopdrachten voor de studie en ik het prettig vind
+werken. Ik heb in het verleden ook SVN gebruikt en ik heb gemerkt dat Git toch
+en aantal voordelen waarvan enkele zijn:
+
+- Git is sneller, het werkt namelijk met een lokale repository. Je werkt dus
+  allereerst vanuit je eigen harde schijf en pas na een definitieve wijziging
+  `push' je je commits naar de server. Bij een CRCS als bijvoorbeeld SVN is er
+  altijd internetverbinding nodig voor een commit waar dit bij Git dus alleen
+  kan worden gebruikt om commits op een remote server te plaatsen (te `pushen') en
+  en ze er weer vandaan te halen (te `fetchen'). Dit werkt erg prettig voor mij
+  persoonlijk als ik op mijn laptop werk en geen beschikking over een
+  internetverbinding heb. Ook bij de communicatie met de server is Git zeer snel,
+  dit komt doordat het is ontwikkeld voor het werken aan de Linux-kernel waarbij
+  snelheid en efficiëntie een must zijn.
+- Door het gedecentraliseerde karakter laat Git toe dat ik met een bepaalde
+  persoon een totaal andere versie kan delen dan met een andere persoon wat erg
+  handig is als je met verschillende personen in meerdere werkgroepen zit.
+
+Ik ga nu niet verdere in op alle voor- en nadelen van verschillende revision
+control systemen, want dat zou een paper op zich worden. Ik wil met bovenstaande
+slechts duidelijk maken waarom ik kies voor Git in deze opdracht.
+
+--- Vragenlijst ---
+
+In de opdracht staat een lijst met een aantal vragen en opdrachten. Deze zal ik
+hier met bijbehorende nummers proberen te beantwoorden.
+
+1.
+Ik gebruik de repository van van het JavaScriptframework JQuery van Github:
+$ git clone https://github.com/jquery/jquery.git
+Dit maakt een map `jquery' aan in mijn home repository.
+
+2.
+$ git diff c1625f6b79b2693ea85f2c16349f708ff203773b 3e0cc815043c2425819743e907a0ce263a7ce164 Rakefile
+diff --git a/Rakefile b/Rakefile
+index 52d7899..4319aa7 100644
+--- a/Rakefile
++++ b/Rakefile
+@@ -9,28 +9,7 @@ test_dir  = File.join( prefix, 'test' )
+ # setting DIST_DIR before calling rake
+ dist_dir  = ENV['DIST_DIR'] || File.join( prefix, 'dist' )
+
+-base_files = %w{
+-  intro
+-  core
+-  support
+-  data
+-  queue
+-  attributes
+-  event
+-  selector
+-  traversing
+-  manipulation
+-  css
+-  ajax
+-  xhr
+-  transports/jsonp
+-  transports/script
+-  transports/xhr
+-  effects
+-  offset
+-  dimensions
+-  outro
+-}.map { |js| File.join( src_dir, "#{js}.js" ) }
++base_files = %w{intro core support data queue attributes event selector traversing manipulation css ajax xhr transports/jsonp transport
+
+ # Sizzle, QUnit and jQuery files/dirs
+ sizzle_dir = File.join( src_dir, "sizzle" )
+@@ -110,11 +89,7 @@ file jq => [dist_dir, base_files].flatten do
+   puts "Building jquery.js..."
+
+   File.open(jq, 'w') do |f|
+-    f.write cat(base_files).
+-      gsub(/@DATE/, date).
+-      gsub(/@VERSION/, version).
+-      gsub(/.function..jQuery...\{/, '').
+-      gsub(/\}...jQuery..;/, '')
++    f.write cat(base_files).gsub(/@DATE/, date).gsub(/@VERSION/, version)
+   end
+ end
+
+3.
+$ git log Rakefile
+
+taddeus@laptoptaddeus:~/jquery$ git log Rakefile
+commit c43b078c6911027fd4124d542446ad0098662f6a
+Author: jaubourg <j@ubourg.net>
+Date:   Thu Jan 6 01:17:31 2011 +0100
+
+    Renamed src/transports to src/ajax (in case we need prefilters in the
+future and to avoid a separate prefilters directory).
+
+commit 981d1e08eb00f4b5c29ad1f3977a45e30c93ad70
+Author: jaubourg <j@ubourg.net>
+Date:   Sat Dec 25 18:54:37 2010 +0100
+
+    Removed re-usability from jXHR object (no more open, send &
+onreadystatechange support). Streamlined the implementation and put it b
+
+commit c1625f6b79b2693ea85f2c16349f708ff203773b
+Author: Jonas Pfenniger <jonas@pfenniger.name>
+Date:   Thu Dec 30 01:38:28 2010 -0600
+
+    Update Rakefile to remove module wrappers (feature parity with make and
+ant). Update Makefile to avoid rebuilding jquery.js when it
+
+... # de rest van de regels heb ik verwijderd omdat de output anders onnodig lang werd
+
+4.
+$ git clone . ../jquery2
+
+5.
+Als 2 mensen hetzelfde bestand bewerken zorgt de eerste die commit ervoor dat er
+een nieuwere versie van het bestand is die de tweede ook wil gaan bewerken
+terwijl die nog op een oudere versie werkt. Dit levert een conflict op.
+
+6.
+Dit zorgt ervoor dat je zelf altijd eerst de laatste versie hebt voor het
+committen, en dat je dus niet (meer) een oude versie aan het bewerken bent.
+Als de tweede persoon uit vraag 5 eerst een pull had gedaan had hij eerst de
+nieuwste versie van de eerste persoon kunnen `mergen' met zijn eigen bewerkingen
+alvorens te committen.
+
+7.
+Ik heb in vraag 5 en 6 al uitgelegd hoe een conflict ontstaat, in het volgende
+voorbeeld zal ik laten zien wat Git in zo'n geval als uitvoer geeft:
+ik wijzig in beide repositories het bestand `Rakefile', in de originele voeg ik
+een regel toe aan het begin van het bestand en in de kopie voeg ik een regel toe
+aan het einde van het bestand. Vervolgens commit ik beide en probeer ik te `pullen':
+
+~/$ cd jquery
+~/jquery$ git commit -m "verwijderd" Rakefile
+~/jquery$ cd ../jquery2
+~/jquery2$ git commit -m "toegevoegd" Rakefile
+~/jquery2$ git pull ../jquery master
+remote: Counting objects: 5, done.
+remote: Compressing objects: 100% (3/3), done.
+remote: Total 3 (delta 2), reused 0 (delta 0)
+Unpacking objects: 100% (3/3), done.
+From ../jquery
+ * branch            master     -> FETCH_HEAD
+Auto-merging Rakefile
+CONFLICT (content): Merge conflict in Rakefile
+Automatic merge failed; fix conflicts and then commit the result.
+~/jquery2$ head Rakefile -n 7
+<<<<<<< HEAD
+
+# -- Added some lines here --
+
+prefix    = File.dirname( __FILE__ )
+=======
+>>>>>>> 92ccfa345d2f7324113b6eda0e5ad82ee94185cf
+
+Vervolgens los ik het conflict op door de drie door Git toegevoegde regels te
+verwijderen en opnieuw te committen:
+
+~/jquery2$ git commit -im "opgelost" Rakefile
+
+hierbij is het -i argument bedoeld om het bestand eerst naar de staging area te
+verplaatsen, dit is het `gebied' van waaruit commits worden gedaan.
+
+8.
+Zoals bij vraag 7 al gezegd gaan commits vanuit de staging area, dus niet direct
+vanuit de working directory. Nieuwe bestanden moeten dus eerst aan de staging
+area worden toegevoegd alvorens te worden gecommit. Dit gebeurt met `'git add':
+~/jquery$ touch newfile.txt
+~/jquery$ git add newfile.txt
+~/jquery$ git status
+# On branch master
+# Your branch is ahead of 'origin/master' by 3 commits.
+#
+# Changes to be committed:
+#   (use "git reset HEAD <file>..." to unstage)
+#
+#   new file:   newfile.txt
+#
+~/jquery$ git commit -m "Bestand toegevoegd" newfile.txt
+
+9.
+Dat is nodig ja, dit gaat met het commando `git mv':
+~/jquery$ git mv newfile.txt newnewfile.txt
+~/jquery2$ git status
+# On branch master
+# Your branch is ahead of 'origin/master' by 4 commits.
+#
+# Changes to be committed:
+#   (use "git reset HEAD <file>..." to unstage)
+#
+#   renamed:    newfile.txt -> newnewfile.txt
+#
+
+10.
+`git reset', dit maakt alle wijzigingen ongedaan tot een bepaalde commit (standaard
+de laatste commit).
+
+11.
+~/jquery$ git revert 6d588aedd30edf89535470b1fe79eddf3a89e4b7
+Finished one revert.
+[master 23a3a9d] Revert "renamed"
+
+12.
+~/jquery$ git rm version.txt
+rm 'version.txt'
+~/jquery$ git commit -m "bestand verwijderd"
+[master 981340e] bestand verwijderd
+~/jquery$ git log | less
+~/jquery$ git revert HEAD
+Finished one revert.
+[master 981340e] Revert "bestand verwijderd"
+
+13.
+Bij het starten van een branch `splitst men zich af' van een andere branch. Dit
+is bijvoorbeeld handig wanneer een nieuwe, experimentele feature moet worden
+ontwikkeld terwijl de huidige ontwikkelingen ook gewoon door moeten kunnen gaan.
+Er wordt dan een nieuwe branch gestart voor de experimentele feature waarin kan
+worden gecommit zonder dat de andere branches daar last van hebben. Wanneer de
+nieuwe feature stabiel is kan deze dan weer worden gemerged met de andere branch.
+In git wordt een branch gestart met `git checkout'.
+
+14.
+