Final major additions to the slide deck

[?]

Sep 17, 2021, 8:18 AM

7RVMAQLPBTL46TDHWJM4RSSB6PUZVLNRQW4CZ6FH6OMAVFCHCUMAC

Dependencies

[2] W7EIQGVR Progress
[3] ENHNSR4Q Add a Fossil vs. Git comparison
[4] NYFLNSVV Add some contents
[5] UH3YXOLF Start the slide deck
[6] SQWPGFUE Finish the demos
[7] 4AZS4L6B Add chapters
[8] BRKBOTWH After-talk changes
[9] 5LKTNB6O LOTS of progress
[10] UYGSVBN7 Start the fossil demo
[11] CBUCBYTV Progress
[12] ARAFRHKU Create the outline of the talk
[13] BZTIJPUB Finish the predictions
[14] 73PQOETU Update slides to 2021 situation

Change contents

file addition: ovh-fire.jpeg (----------)

[4.1221]
file addition: fed-up-with-github.png (----------)

[4.1204]
file addition: how-about-pijul-nest.png (----------)

[4.1204]
file addition: snapshot-vs-patch.png (----------)

[4.1204]
edit in index.html at line 81

[2.3448]

[2.3448]

</li>
<li class="fragment fade-in-then-semi-out">"Fossil vs. Git" (by the Fossil team)
 <a href="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</a>
replacement in index.html at line 89

[2.3781]→[2.3781:3867](∅→∅)

<li class="fragment fade-in-then-semi-out">"The Pijul Manual"

[2.3781]

[2.3867]

<li class="fragment fade-in-then-semi-out">Try out Pijul @ katacoda.com
replacement in index.html at line 91

[2.3911]→[2.3911:4052](∅→∅)

href="https://pijul.org/manual/introduction.html">https://pijul.org/manual/introduction.html</a>

[2.3911]

[2.4052]

href="https://www.katacoda.com/ysndr/scenarios/pijul">https://www.katacoda.com/ysndr/scenarios/pijul</a>
edit in sections/5-fossil.md at line 189

[3.1340]

---

# Fossil for Git users

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

[4.1395]

[4.1395]

And the Pijul Nest can be a good alternative to GitHub if you're fed up with them for wanting to own everything anyone has ever done.

---

![fed-up-with-github](img/fed-up-with-github.png "Fed up with Github!")
![how-about-pijul-nest](img/how-about-pijul-nest.png "How about Pijul Nest?") 
replacement in sections/6-pijul.md at line 76

[4.82]→[4.53954:53975](∅→∅),[4.53954]→[4.53954:53975](∅→∅)

It stores snapshots.

[4.82]

[4.1427]

It stores snapshots of files and computes the differences when they are needed.

---



<https://www.katacoda.com/ysndr/scenarios/pijul/assets/comparison.png> 
replacement in sections/6-pijul.md at line 152

[4.2765]→[4.2765:2795](∅→∅)

* Usability needs to improve

[4.2765]

[4.2822]

<ul>

<li>Usability needs some work</li>
<a href="https://mivehind.net/2017/04/09/pijul-first-thoughts">https://mivehind.net/2017/04/09/pijul-first-thoughts</a>


<li>Complete rewrite in progress for v1.0</li>
<a href="https://pijul.org/posts/2020-11-07-towards-1.0">https://pijul.org/posts/2020-11-07-towards-1.0</a>

</ul>
replacement in sections/6-pijul.md at line 163

[4.2823]→[4.54007:54062](∅→∅)

<https://mivehind.net/2017/04/09/pijul-first-thoughts>

[4.2823]

[4.4236767]

note:

So in the demo I used Pijul 0.12, which was clearly labeled as a preview version for research purposes.
So not production-ready in the slightest.

Now what would you do if you're building a version control system and a bug has to be fixed?
This turns out to be quite a challenge.
Version control systems that use itself for its versioning (bootstrapping) are famously hard when dealing with bugs.
If you're building a compiler, for example, bootstrapping can be done one step at a time, and previous versions are always available to compile your current one.
But a version control system has the additional problem that the previous versions might not always be easily accessible if there is a bug.

So this is exactly what happened to Pijul.
A few months after the release of Pijul 0.12, a user reported a defect regarding the unrecording of patches that were previously involved in a conflict.
After some time a solution was found, but it meant that a new patch format was needed, along with a few new algorithms.
So, Pijul had to be rewritten from scratch to make it all work, which obviously resulted in a lot of breaking changes.
replacement in sections/6-pijul.md at line 181

[4.7972986]→[4.1598:1621](∅→∅)

## Pijul for Git users

[4.7972986]

[4.7972986]

## Pijul towards v1.0
replacement in sections/6-pijul.md at line 183

[4.7972987]→[4.4236769:4236818](∅→∅)

<https://nest.pijul.com/tae/pijul-for-git-users>

[4.7972987]

* New change format; 'patches' are now called 'changes' 
* 'Branches' are now called 'channels' 
* Better support for large files and repositories by compressing changes 
* Interactive recording is replaced by a 'change draft screen' 
* Version identifiers that don't depend on any order 
* Inclusive author names 
* Documentation is lagging a bit 

note:

So this is what the Pijul maintainers are doing to make Pijul production-ready.

* change draft screen

Which look sa bit like the interactive rebase screen in Git.

* documentation is lagging

I've used the Pijul v1.0-alpha for a bit in preparation for this talk and I found that the documentation is lagging a bit.
It used to be better in v0.12.
Which is no surprise, because the rewrite is not done yet.
Moreover, the Pijul maintainers had to deal with the setbacks that were caused by a fire in their data center.

---



<https://www.reuters.com/article/us-france-ovh-fire-idUSKBN2B20NU> 

note:

Maybe you've heard about it; it was a fire in the OVHcloud data center in Paris, France, that happened in March.

Overall, I think Pijul is quite promising, but it needs some work in its current alpha phase.
So some of its popularity will be depending on how they will get to beta and stable versions later this year.
edit in sections/7-predictions.md at line 201

[4.57780]

[4.1671]

Especially since this is now so easy in Azure DevOps.
replacement in sections/7-predictions.md at line 206

[4.1886]→[4.1886:2060](∅→∅)

Should Github announce in the meantime that they're gonna support Pijul, for example, then Pijul will gain users a lot faster and might even take the #2 spot from Mercurial.

[4.1886]

[4.2060]

Should Github or GitLab announce in the meantime that they're gonna support Fossil, for example, then Fossil will gain users a lot faster and might even take the #2 spot from Mercurial.
edit in sections/7-predictions.md at line 208

[4.2061]

So this is my prediction when hosting platform keep supporting what they currently support.
If that changes, obviously these predictions will have to change, too.