package misc;

<https://pxhere.com/en/photo/652221>  <!-- .element: class="attribution" -->

<https://pxhere.com/en/photo/652221> <!-- .element: class="attribution" -->

## 'Github in a box'

## Cathedral vs. Bazaar

* repository UI
* wiki, ticketing & bug tracking
* embedded documentation
* technical notes
* forum

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.

FIXME: 
So there's no need to use 3rd party products; after cloning a repo you have a fully-featured developer website available.

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.

* Well-suited for startups and small-scale projects ('SQLite-style')
* But not really for large-scale open-source development ('Linux-style')

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.

<!-- TODO: oefen de demo 
En gebruik daarbij doitlive of demo-magic -->

    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"

    fossil ui

    fossil descendants [hash]

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.

### 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> <!-- .element: class="attribution" -->

note:
Because Fossil repositories are stored in a single file.

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

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

* **interactive** recording

<!-- FIXME: dit gaan we niet allemaal demonstreren, zie de notes --->

* Ignore
* Removing patches
* Patch dependencies

  * (but maybe we don't need them)

  * (but maybe we don't need them - https://nest.pijul.com/tae/pijul-for-git-users)

<!-- TODO: oefen de demo 
En gebruik daarbij doitlive of demo-magic -->

### 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

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.

    pijul checkout use-math-random
    pijul apply [hash]
    pijul add Sample.java
    pijul record

### 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> <!-- .element: class="attribution" -->

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.