diff -rN -u old-darcs-book/en/01-introduction.md new-darcs-book/en/01-introduction.md
--- old-darcs-book/en/01-introduction.md	1970-01-01 00:00:00.000000000 +0000
+++ new-darcs-book/en/01-introduction.md	2024-11-24 07:53:53.800408434 +0000
@@ -0,0 +1,170 @@
+Introduction
+============
+
+Welcome!
+--------
+
+So, you want to learn version control, or more specifically, you want to learn
+`darcs`? That's great! I hope this book will give you an interesting perspective
+on how to manage your projects and enable to work with other people all around
+the world. I want to encourage you to follow along with the examples and play
+around with them a bit. Things sometimes happen to make a lot more sense when
+you type them yourself and see things happening right in front of you.
+
+In this book I will assume that you are using a Unix or Unix-like
+operating system.
+
+What's version control?
+-----------------------
+
+Ever had to write an imported document over an extended period of time? Then you
+probably know how this works. You start with `important.txt` and a
+couple of weeks you end up with a folder full of files like this
+
+```
+-rw-r--r--   1 raichoo  raichoo   19182 Jun  7 23:23 important.txt
+-rw-r--r--   1 raichoo  raichoo  121890 Jun  8 15:04 important_final.txt
+-rw-r--r--   1 raichoo  raichoo   48245 Jun 11 18:48 important_really_final.txt
+-rw-r--r--   1 raichoo  raichoo   35099 Jun 11 21:09 important_final_1.txt
+...
+-rw-r--r--   1 raichoo  raichoo    6887 Jun 22 18:34 important_final_20487.txt
+```
+
+And if that wasn't confusing enough, you then end up in a situation where you
+want one part of an older revision in your final version. To make matters even
+worse, at some point in time a friend of yours voulunteered to write some other
+portion of that document and you start mailing full copies of your document back
+and forth while you are trying to stitch all of your work together. Needless to
+say that this isn't much fun but a rather frustrating task that makes working on
+your project much less enjoyable.
+
+Enter version control! With version control you can keep track of all the
+changes you have made to your document. You want to revert a portion of your
+project to a previous revision? No problem, version control takes care of that!
+It keeps track of the history of your project as time progresses and gives you
+access to older versions of your project. Deleted something important? Like the
+older version of a piece of text better than the new one and want it back? No
+problem! If it's in your version control you have access to it. You can even
+share your work with others and pull in their changes without doing all the work
+by hand! Magnificent!
+
+What's a DVCS?
+--------------
+
+The world of computering is full of acronyms and version control is no
+exception. `darcs` is a so called **DVCS**, which stands for **distributed
+version control system**. Now that's a mouthful. But what does it mean? Remember
+that a version control system keeps track of all the changes you have made to
+your project? Now here is where the distributed part comes in. Everyone working
+with you on a project has a complete copy of that projects history on their
+computer, so you don't even need to be online to have access to all of that
+information, and they can make their own changes to it and share those with you.
+Nifty huh? We say that every party has their own copy of the project's
+**repository**. That's not always the case, there are so called **centralized
+version control systems** like `svn` where you only have the most recent
+revision of the project our your machine. To access older ones you need to be
+able to access a server.
+
+Why `darcs`?
+------------
+
+In the world of DVCS `darcs` is a pretty unique animal. Most version control
+systems take a **snapshot** of your work and each snapshot depends on a previous
+snapshot. `darcs` doesn't do that. Instead `darcs` keeps track of what actually
+changes. We call that this approach **patch based** and it has some cool effects
+when working with multiple people on a single project.
+
+Let's compare that snapshot based approach with the way `darcs` does it so you
+can see what I mean.
+
+I'm working with my friends tauli and jeanny on a project. tauli has written
+some great code (let's call that patch A) and jeanny has provided some awesome
+illustrations (let's call that patch B) and I want to pull their patches into my
+local copy of the project. gimbar, another friend of mine, wants to do the same
+to their copy.
+
+First, let's look at the snapshot based approach and we are using a tool called
+`git` to illustrate this. If you don't fully understand what's happining here,
+that's fine. It's not necessary to use `darcs` efficiently.
+
+gimbar pulls in jeanny's and then tauli's patches. gimbar now has the following
+patches in their repository.
+
+```
+commit fd9d393916a76bf716d4af6485556182aaaab5a2 (HEAD -> master)
+Merge: c083eb1 425b39d
+Author: gimbar
+Date:   Tue Jun 26 19:00:37 2018 +0200
+
+    Merge
+
+commit 425b39d34417584427ed47218803056974afdfd8
+Author: tauli
+Date:   Tue Jun 26 18:59:53 2018 +0200
+
+    some code
+
+commit c083eb19fab5f67694d3dc18e283dcc56798a0aa
+Author: jeanny
+Date:   Tue Jun 26 18:59:42 2018 +0200
+
+    graphics
+
+commit 85b41da2f0a273c6691ee56b13dfe3590d4d0418 (origin/master, origin/HEAD)
+Author: raichoo
+Date:   Tue Jun 26 18:58:52 2018 +0200
+
+    previous work
+
+```
+
+Now I come along, sadly I don't know that gimbar already pulled in the other
+patches and for some reason I happen to pull in tauli's patches first and then
+jeanny's. I now have the following patches applied to my repository.
+
+```
+commit 48f2fa962e67f7bbb12d1f4d6d3b823e1905b16c (HEAD -> master)
+Merge: 425b39d c083eb1
+Author: raichoo
+Date:   Tue Jun 26 19:00:14 2018 +0200
+
+    Merge
+
+commit 425b39d34417584427ed47218803056974afdfd8
+Author: jeanny
+Date:   Tue Jun 26 18:59:53 2018 +0200
+
+    graphics
+
+commit c083eb19fab5f67694d3dc18e283dcc56798a0aa
+Author: tauli
+Date:   Tue Jun 26 18:59:42 2018 +0200
+
+    some code
+
+commit 85b41da2f0a273c6691ee56b13dfe3590d4d0418
+Author: raichoo <raichoo@googlemail.com>
+Date:   Tue Jun 26 18:58:52 2018 +0200
+
+    previous work
+
+```
+
+Now `git` created those *Merge* patches for us, but they are quite different for
+gimbar's and me. They have a different author, a different timestamp etc. Now we
+have to coordinate how we proceed because we are not working on the same
+snapshot anymore.
+
+In the snapshot based approach we end up with both of our repositories in
+different states even though both of us pulled in the same patches, we just have
+pulled them in in a different order.
+
+`darcs` is different because it's **patch based**. In `darcs` a repository
+consists of a set of changes and these changes are represented by a patch. The
+order in which we pull them in does not matter. So in the above example gimbar
+and I end up with our repositories being in the same state even though we have
+pulled in the changes in a different order. This approach is great when working
+together with a couple of people because all of them can mix and match and in
+the end we don't need to do extra work to bring everything back together.
+
+Of course I've been using `darcs` to write this book. :)