From 79a5ee985199c7b12392ef168a042309b6fa4e29 Mon Sep 17 00:00:00 2001 From: Owen Jacobson Date: Fri, 17 Jul 2015 01:30:44 -0400 Subject: Fixup image links for Dokku-based version of site. --- .html/dev/builds.html | 2 +- .html/dev/merging-structural-changes.html | 6 +++--- .html/email.html | 2 +- wiki/dev/builds.md | 2 +- wiki/dev/merging-structural-changes.md | 6 +++--- wiki/email.md | 2 +- 6 files changed, 10 insertions(+), 10 deletions(-) diff --git a/.html/dev/builds.html b/.html/dev/builds.html index e909182..5626a4e 100644 --- a/.html/dev/builds.html +++ b/.html/dev/builds.html @@ -80,7 +80,7 @@ person—“creativity,” “morality,” “curiosity,” and so on.

Extensible. Understood. In the middle tier: Simple. Fast. Unit tests. Part of the project. Environment independent. At the top: Metrics. Parallel builds. Acceptance tests. Product caching. IDE -integration." src="/media/dev/builds/buildifesto-pyramid">

+integration." src="/media/dev/builds/buildifesto-pyramid.png">

Builds, and software engineering as a whole, can be described the same way: at the top of the hierarchy is a working system that solves a problem, and at the bottom are the things you need to have software at all. If you don't meet diff --git a/.html/dev/merging-structural-changes.html b/.html/dev/merging-structural-changes.html index e5c8795..a019d9c 100644 --- a/.html/dev/merging-structural-changes.html +++ b/.html/dev/merging-structural-changes.html @@ -63,7 +63,7 @@ sadly, performed dismally: none of the merge scenarios tested retained content changes when merging structural changes to the same files.

The Preferred Outcome

Both changes survive the -merge.

+merge." src="/media/dev/merging-structural-changes/ideal-merge-results.png">

The diagram above shows a very simple source tree with one directory, dir-a, containing one file with two lines in it. On one branch, the file is modified to have a third line; on another branch, the directory is renamed to dir-b. @@ -73,7 +73,7 @@ changes: the file has three lines, and the directory has a new name.

merging.

Subversion

Subversion loses the content -change.

+change." src="/media/dev/merging-structural-changes/subversion-merge-results.png">

There are two merge scenarios in this diagram, with almost the same outcome. On the left, a working copy of the branch where the file's content changed is checked out, then the changes from the branch where the structure changed are @@ -105,7 +105,7 @@ which is not as good as automatically merging it but far better than silently ignoring changes.

Mercurial

Mercurial preserves the content -change.

+change." src="/media/dev/merging-structural-changes/mercurial-merge-results.png">

Interestingly, there are tools which get this merge scenario right: the diagram above shows how Mercurial handles the same two tests. Since its changeset language does include an “object diff --git a/.html/email.html b/.html/email.html index 95df2a8..8f64a63 100644 --- a/.html/email.html +++ b/.html/email.html @@ -46,7 +46,7 @@

An email appears! Aww, man. Will I think differently after reading it? If yes, then read immediately. If no, then will I act differently after reading it? If yes, then read immediately. If no, then is it from someone funny? If -yes, then read immediately. If no, UNREAD FOREVER.

+yes, then read immediately. If no, UNREAD FOREVER." src="/media/email/flowchart.png">

I get a lot of email, often while I'm in the middle of something thought-intensive. Managing interruptions and my attention means I have to triage emails based on diff --git a/wiki/dev/builds.md b/wiki/dev/builds.md index 8f334a1..abe3d19 100644 --- a/wiki/dev/builds.md +++ b/wiki/dev/builds.md @@ -37,7 +37,7 @@ person—“creativity,” “morality,” “curiosity,” and so on. Extensible. Understood. In the middle tier: Simple. Fast. Unit tests. Part of the project. Environment independent. At the top: Metrics. Parallel builds. Acceptance tests. Product caching. IDE -integration.](/media/dev/builds/buildifesto-pyramid) +integration.](/media/dev/builds/buildifesto-pyramid.png) Builds, and software engineering as a whole, can be described the same way: at the top of the hierarchy is a working system that solves a problem, and at the diff --git a/wiki/dev/merging-structural-changes.md b/wiki/dev/merging-structural-changes.md index a47fdcc..d1c7a9c 100644 --- a/wiki/dev/merging-structural-changes.md +++ b/wiki/dev/merging-structural-changes.md @@ -17,7 +17,7 @@ changes when merging structural changes to the same files. ## The Preferred Outcome ![Both changes survive the -merge.](/media/dev/merging-structural-changes/ideal-merge-results) +merge.](/media/dev/merging-structural-changes/ideal-merge-results.png) The diagram above shows a very simple source tree with one directory, `dir-a`, containing one file with two lines in it. On one branch, the file is modified @@ -31,7 +31,7 @@ merging. ## Subversion ![Subversion loses the content -change.](/media/dev/merging-structural-changes/subversion-merge-results) +change.](/media/dev/merging-structural-changes/subversion-merge-results.png) There are two merge scenarios in this diagram, with almost the same outcome. On the left, a working copy of the branch where the file's content changed is @@ -69,7 +69,7 @@ ignoring changes. ## Mercurial ![Mercurial preserves the content -change.](/media/dev/merging-structural-changes/mercurial-merge-results) +change.](/media/dev/merging-structural-changes/mercurial-merge-results.png) Interestingly, there are tools which get this merge scenario right: the diagram above shows how [Mercurial](http://www.selenic.com/mercurial/) handles diff --git a/wiki/email.md b/wiki/email.md index d7450eb..53350a8 100644 --- a/wiki/email.md +++ b/wiki/email.md @@ -3,7 +3,7 @@ ![An email appears! Aww, man. Will I think differently after reading it? If yes, then read immediately. If no, then will I act differently after reading it? If yes, then read immediately. If no, then is it from someone funny? If -yes, then read immediately. If no, UNREAD FOREVER.](/media/email/flowchart) +yes, then read immediately. If no, UNREAD FOREVER.](/media/email/flowchart.png) I get a lot of email, often while I'm in [the middle of something thought-intensive](http://blog.ninlabs.com/2013/01/programmer-interrupted/). -- cgit v1.2.3