Finish the demos

[?]

Jun 5, 2019, 9:18 PM

SQWPGFUETQPYAW2VZRIDZWGXQN4GCMSPHYQ4PLWMESLDJTPACGXAC

Dependencies

[2] UYGSVBN7 Start the fossil demo
[3] ARAFRHKU Create the outline of the talk
[4] PMBAMPBI Finish the title slide
[5] 5LKTNB6O LOTS of progress
[6] 4AZS4L6B Add chapters
[7] NYFLNSVV Add some contents

Change contents

file move: MyRandom.java (----------) → MyRandom.java (---r------)

[3.4217140]

[3.4217158]
edit in misc/MyRandom.java at line 1

[3.4217158]→[3.4217159:4217174](∅→∅)

package misc;
replacement in sections/5-fossil.md at line 5

[3.2041101]→[3.4235177:4235254](∅→∅)

<https://pxhere.com/en/photo/652221> 

[3.2041101]

[3.7973228]

<https://pxhere.com/en/photo/652221> 
edit in sections/5-fossil.md at line 57

[3.4235472]

[2.2775]

## 'Github in a box'
replacement in sections/5-fossil.md at line 60

[2.2776]→[2.2776:2800](∅→∅)

## Cathedral vs. Bazaar

[2.2776]

[3.4235472]

* repository UI
* wiki, ticketing & bug tracking
* embedded documentation
* technical notes
* forum
replacement in sections/5-fossil.md at line 67

[2.2807]→[2.2807:3163](∅→∅)

FIXME:
Fossil and Git promote different development styles. Git promotes a "bazaar" development style in which numerous anonymous developers make small and sometimes haphazard contributions. Fossil promotes a "cathedral" development model in which the project is closely supervised by an highly engaged architect and implemented by a clique of developers.

[2.2807]

[2.3163]

FIXME:
So there's no need to use 3rd party products; after cloning a repo you have a fully-featured developer website available.
replacement in sections/5-fossil.md at line 70

[2.3164]→[2.3164:3768](∅→∅)

Nota Bene: This is not to say that Git cannot be used for cathedral-style development or that Fossil cannot be used for bazaar-style development. They can be. But those modes are not their design intent nor their low-friction path.

Git encourages a style in which individual developers work in relative isolation, maintaining their own branches and occasionally rebasing and pushing selected changes up to the main repository. Developers using Git often have their own private branches that nobody else ever sees. Work becomes siloed. This is exactly what one wants when doing bazaar-style development.

[2.3164]

[2.3768]

* Well-suited for startups and small-scale projects ('SQLite-style')
* But not really for large-scale open-source development ('Linux-style')
edit in sections/5-fossil.md at line 73

[2.3769]→[2.3769:4324](∅→∅),[2.4324]→[3.4235532:4235533](∅→∅),[3.4235532]→[3.4235532:4235533](∅→∅)

Fossil, in contrast, strives to keep all changes from all contributors mirrored in the main repository (in separate branches) at all times. Work in progress from one developer is readily visible to all other developers and to the project leader, well before the code is ready to integrate. Fossil places a lot of emphasis on reporting the state of the project, and the changes underway by all developers, so that all developers and especially the project leader can maintain a better mental picture of what is happening, and better situational awareness.
replacement in sections/5-fossil.md at line 86

[2.4442]→[2.4442:4514](∅→∅)



[2.4442]

[2.4514]

cd ~/development/fossil
mkdir demo
fossil new demo.repo
cd demo
fossil open ../demo.repo
touch Sample.java
fossil changes
fossil add .
fossil commit -m "message"
edit in sections/5-fossil.md at line 97

[2.4543]

[2.4543]

fossil ui
edit in sections/5-fossil.md at line 101

[2.4584]

[3.4235654]

fossil descendants [hash]
replacement in sections/5-fossil.md at line 104

[3.4235655]→[3.4235655:4235877](∅→∅)

Inhoud van de demo:
* Schrijf een klasse die een random nummer genereert.
* Eerste implementatie: gooi een dobbelsteen.
* Tweede implementatie: (int) Math.random() * 6
* deze implementatie moet een conflict veroorzaken.

[3.4235655]

[3.7973256]

### Close

fossil close

---

## The Bad

* Dealing with large files
* Dealing with large commits

<https://www.omiyagames.com/blog/2014/02/15/farewell-fossil-version-control> 
edit in sections/5-fossil.md at line 117

[3.7973257]

[3.7973257]

note:
Because Fossil repositories are stored in a single file.
replacement in sections/5-fossil.md at line 124

[3.7973262]→[3.4235878:4235944](∅→∅)

<https://www.fossil-scm.org/home/doc/trunk/www/fossil-v-git.wiki>

[3.7973262]

<https://www.fossil-scm.org/home/doc/trunk/www/fossil-v-git.wiki>
edit in sections/6-pijul.md at line 28

[3.1076]

[3.1076]

* **interactive** recording
edit in sections/6-pijul.md at line 66

[3.1447]

[3.1447]


edit in sections/6-pijul.md at line 71

[3.1468]→[3.1468:1517](∅→∅)

* Ignore
* Removing patches
* Patch dependencies
replacement in sections/6-pijul.md at line 72

[3.1528]→[3.4236323:4236358](∅→∅)

* (but maybe we don't need them)

[3.1528]

[3.4236358]

* (but maybe we don't need them - https://nest.pijul.com/tae/pijul-for-git-users)
replacement in sections/6-pijul.md at line 77

[3.1568]→[2.5283:5355](∅→∅)



[3.1568]

[3.1592]

### Up and running

pijul init demo
touch Sample.java
pijul status
pijul add Sample.java
mkdir directory
pijul add directory
pijul status
pijul record

(Here y means yes, n means no, k means undo and remake last decision, a means include this and all remaining patches, d means include neither this patch nor the remaining patches and i means ignore this file locally (i.e. it is added to .pijul/local/ignore).)

### Generating random numbers

!!! Throw the dice on stage !!!

public class Sample {

public static void main(String... args) {
System.out.println(random());
}

private static int random() {
// Chosen by fair dice roll; guaranteed to be random.
return 4;
}
}

pijul add Sample.java
pijul record

### Handling conflicts

pijul fork use-math-random
pijul checkout use-math-random

private static int random() {
return (int)(Math.random() * 6);
}

pijul add Sample.java
pijul record

pijul checkout master
pijul fork use-random-class
pijul checkout use-random-class

private static int random() {
return new java.util.Random().nextInt(7);
}

pijul add Sample.java
pijul record
replacement in sections/6-pijul.md at line 133

[3.1593]→[3.4236381:4236709](∅→∅)

Inhoud van de demo:
* Schrijf een klasse die een random nummer genereert.
* Eerste implementatie: gooi een dobbelsteen.
* Tweede implementatie: (int) Math.random() * 6
* deze implementatie moet een conflict veroorzaken.
* Derde implementatie: java.util.Random.nextInt(7).
* deze implementatie moet een conflict veroorzaken.

[3.1593]

[3.4236709]

pijul checkout use-math-random
pijul apply [hash]
pijul add Sample.java
pijul record
edit in sections/6-pijul.md at line 139

[3.4236767]

[3.4236767]

### Nest Demo

<https://nest.pijul.com/pijul_org/pijul>

---

## The Bad

* Usability needs to improve
* FIXME: verzin er nog een

<https://mivehind.net/2017/04/09/pijul-first-thoughts> 
edit in sections/6-pijul.md at line 158

[3.4236818]

FIXME: verwerk dit nog ergens (bron: https://news.ycombinator.com/item?id=19090514)

I've not used Pijul, but I used Darcs — which Pijul is essentially an improved clone of — for half a decade, and I assume it's roughly the same.
The patch model is incredible. Think of "git cherry-pick". Imagine you could use that instead of "git merge" or "git rebase" for all your work. Imagine that every time you cherry-picked, it would tell you which additional commits you'd need, and then pick them for you. And that when you merged your heavily cherry-picked branch back into the mainline, it just worked. That's Pijul/Darcs.

One doesn't have to understand the "theory of patches" to use Pijul/Darcs. As a user, you just work with changes, just like Git. But the UX is much simpler than Git — in a good way.

I remember switching from Darcs to Git back in 2008 or so. It was like switching out a sleek spaceship [] for an old rusty, clanking pickup truck. Git has gotten better over the years, but ultimately, I think Github was the killer app, not Git. Going back technical merits alone, Darcs and Mercurial "should" have won that battle.