Start the fossil demo

[?]

Jun 5, 2019, 5:22 AM

UYGSVBN7QR3YK6LTBMYIHDDVZPG25MBKPN2JLFDVCY3NEEPCQBAQC

Dependencies

[2] 36IPNPIS Handle a few TODOs
[3] S55XICBM Fix speaker notes
[4] PMBAMPBI Finish the title slide
[5] 4AZS4L6B Add chapters
[6] NYFLNSVV Add some contents
[7] 5LKTNB6O LOTS of progress
[8] WYULWETJ Reorganize
[*] UH3YXOLF Start the slide deck
[*] ARAFRHKU Create the outline of the talk

Change contents

edit in index.html at line 100

[3.4217037]

[3.4217037]

<li>"The Pijul Manual"
<br/><small><a href="https://pijul.org/manual/introduction.html">https://pijul.org/manual/introduction.html</a></small>
</li>
file addition: fossil-demo.sh (----------)

[3.4217140]
replacement in sections/4-four-new-kids-on-the-block.md at line 18

[3.7971698]→[3.7971698:7971716](∅→∅)

* Veracity (2010)

[3.7971698]

[3.7971716]

* Veracity (2011)
edit in sections/4-four-new-kids-on-the-block.md at line 25

[2.2744861]

[3.4234785]

---

# Veracity

* Distributed version control
* Issue tracking and wiki, also distributed



<http://www.veracity-scm.com> 

---

## But
#### Veracity is not going to be 'the Git killer'

* Development status: web site appears unmaintained; latest release March 25, 2013
* Hosting platform onveracity.com hasn't been online since February 4, 2015

note:
FIXME - why was this one even in the abstract and why that's the only reason I have included it.
replacement in sections/4-four-new-kids-on-the-block.md at line 84

[2.2745643]→[2.2745643:2745670](∅→∅)

* not open-source software

[2.2745643]

[2.2745670]

* it's not open-source software
edit in sections/4-four-new-kids-on-the-block.md at line 93

[2.2746069]→[2.2746069:2746075](∅→∅),[2.2746075]→[3.4234914:4234925](∅→∅),[3.7971766]→[3.4234914:4234925](∅→∅),[3.4234925]→[3.7283:7284](∅→∅),[3.7971892]→[3.7283:7284](∅→∅),[3.7284]→[3.4234926:4235175](∅→∅)

---

# Veracity



note:
TODO: opnemen:
* Development status: web site appears unmaintained; latest release March 25, 2013
* http://veracity-scm.com/compare/
* onveracity.com (offline :()
edit in sections/5-fossil.md at line 10

[3.4235282]→[3.4235282:4235365](∅→∅)

FIXME: link opnemen in slides:
* https://www.fossil-scm.org/index.html/dir?ci=tip
replacement in sections/5-fossil.md at line 14

[3.4235404]→[3.4235404:4235437](∅→∅)

* TODO
* **feature** elaboration

[3.4235404]

[3.4235437]

* **distributed** version control
* **integrated bug tracking**, wiki, forum and technotes
* built-in **web interface**
* **autosync** mode
* show **descendants** of a checkin
* supports operations on multiple repositories (`fossil all`)

<https://www.fossil-scm.org> 

note:
FIXME: uitbreiden

* **autosync mode** - push automatically after each check-in
replacement in sections/5-fossil.md at line 32

[3.4235459]→[3.4235459:4235466](∅→∅)

* TODO

[3.4235459]

[3.4235466]

* Written in C and SQL
* Is the VCS of choice for the SQLite project
* 'Github in a box'
* Free code hosting at:
* Chisel - <http://chiselapp.com/>
* SourceForge - <http://fossilrepos.sourceforge.net>

note:
Though the SourceForge implementation is a bit unorthodox.
Because Fossil needs just an SQLite database to generate static HTML.
So any hosting space provider would do the job.

---

## Uses a relational database

note:
FIXME:
The difference is that Git stores its objects as individual files in the ".git" folder or compressed into bespoke "pack-files", whereas Fossil stores its objects in a relational (SQLite) database file. To put it another way, Git uses an ad-hoc pile-of-files key/value database whereas Fossil uses a proven, general-purpose SQL database. This difference is more than an implementation detail. It has important consequences.

With Git, one can easily locate the ancestors of a particular check-in by following the pointers embedded in the check-in object, but it is difficult to go the other direction and locate the descendants of a check-in. It is so difficult, in fact, that neither native Git nor GitHub provide this capability. With Git, if you are looking at some historical check-in then you cannot ask "what came next" or "what are the children of this check-in".
edit in sections/5-fossil.md at line 54

[3.4235467]

[3.4235467]

Fossil, on the other hand, parses essential information about check-ins (parents, children, committers, comments, files changed, etc.) into a relational database that can be easily queried using concise SQL statements to find both ancestors and descendents of a check-in.
edit in sections/5-fossil.md at line 57

[3.4235472]

[3.4235472]

## Cathedral vs. Bazaar
replacement in sections/5-fossil.md at line 60

[3.4235473]→[3.4235473:4235532](∅→∅)



[3.4235473]

[3.4235532]

note:
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.

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.

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 74

[3.4235553]→[3.4235553:4235601](∅→∅)



[3.4235553]

[3.4235601]

* Up and running
* Using the web interface (`fossil ui`)
* Retrieving descendants of a checkin
replacement in sections/5-fossil.md at line 80

[3.4235630]→[3.4235630:4235654](∅→∅)

TODO: demo voorbereiden

[3.4235630]

[3.4235654]

### Up and running



### Using the web interface

### Retrieving descendants of a checkin
edit in sections/6-pijul.md at line 20

[3.4236178]→[3.865:872](∅→∅),[3.7972985]→[3.865:872](∅→∅),[3.872]→[3.4236179:4236238](∅→∅)

note:
FIXME: link over Pijul toevoegen:
* https://www.pijul.com/
edit in sections/6-pijul.md at line 29

[3.1077]

[3.1077]

<https://www.pijul.com> 

note:
Darcs is a version control system from 2003 that is also patch-based.
However it didn't gain much popularity due to the fact that it was very slow.
replacement in sections/6-pijul.md at line 41

[3.1150]→[3.1150:1200](∅→∅)

* comes with a hosting platform called 'The Nest'

[3.1150]

[3.1200]

* free code hosting at <https://nest.pijul.com>
replacement in sections/6-pijul.md at line 54

[3.4236289]→[3.4236289:4236322](∅→∅)



[3.4236289]

[3.1427]

* A patch is an intuitive atomic unit of work.
* It focuses on *changes*, instead of *differences between snapshots* (i.e. Git commits).
* Applying or unapplying a patch *doesn't change* its identity.
* The end result of applying several patches is always the same, regardless of the order in which they were applied.

note:
FIXME: toelichting schrijven
edit in sections/6-pijul.md at line 66

[3.1448]

[3.1448]

* Up and running
edit in sections/6-pijul.md at line 74

[3.4236380]

[3.1561]

* Nest demo - <https://nest.pijul.com/pijul_org/pijul>
replacement in sections/6-pijul.md at line 77

[3.1568]→[3.1568:1592](∅→∅)

TODO: demo voorbereiden

[3.1568]

[3.1592]