Naam:        Taddeüs Kroes
Student nr.: 6054129
Studie:      Informatica
Datum:       09-01-2011

--- 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 enkelen 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).  Je zou ook `git checkout' kunnen gebruiken.

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 branch <branchname>'. De huidige
branchname is standaard `master', je kunt naar de nieuwe branch switchen m.b.v.
`git checkout <branchname>'. Daar kun je dan bijvoorbeeld een bestand aanmaken,
toevoegen en committen en weer terugswitchen naar de master branch
(achtereenvolgens git branch - git checkout - git add - git commit - git checkout).

14.
Met cherrypicking kunnn wijzigingen van bepaalde commits worden toegepast. Stel
bijvoorbeeld dat ik een website aan het ontwikkelen ben met wat php-bestanden en
een css-bestand. Ik wil wat experimenteren met een aanmeldingsformulier en start
hiervoor een nieuwe branch `form'. Tijdens het maken van het formulier ontdek ik
enkele fouten in het css-bestand die ik verbeter en commit. Nu blijf ik steken
bij het ontwikkelen van het formulier en ik switch terug naar de master branch,
hier heb ik echter nog steeds de fouten in de CSS die ik verbeterd wil hebben.
Hiervoor zoek ik in de `form' branch naar de betreffende commit(s) en pas deze
toe op de master branch zodat ik niet handmatig hoef te mergen:
$ git checkout form
$ vim style.css # hier breng ik de wijzigen aan
$ git commit -m "CSS bugfixes" style.css
$ vim ... # ga verder met het ontwikkelen van het formulier
$ git log | less # vind de ID van de bewuste commit
$ git checkout master
$ git cherry-pick d515068ee807efef29b6c8406171be4725d7154f

15.
Een hook is een script dat wordt getriggered bij een bepaalde gebeurtenis in de
repository, dit soort scripts worden geplaatst in de `.git/hooks/' map. Een heel
simpel voorbeeld is een script `.git/hooks/pre-commit' met de regel `make'. Dit
zorgt ervoor dat altijd de Makefile wordt aangeroepen voordat een commit wordt
toegepast.

~/jquery$ vim version.txt # een willekeurige wijziging
~/jquery$ git commit -m "Test of pre-commit hook" version.txt
Pulling test/qunit... # zoals te zien wordt nu eerst de Makefile aangeroepen
Pulling src/sizzle...
Checking jQuery against JSLint...
JSLint check passed.
jQuery build complete.
[master e4205d9] Test of pre-commit hook. # Makefile uitgevoerd, nu wordt de
                                            commit daadwerkelijk gedaan
 1 files changed, 3 insertions(+), 1 deletions(-)

