#introduction time!

Hello! We're Review Board, an #opensource #CodeReview / #DocReview tool from @chipx86 (me!) and others at Beanbag.

https://reviewboard.org

We've been around since 2006. Our product's built to work with all kinds of workflows and SCMs (from #CVS to #Git to enterprise ones like #ClearCase, #CliosoftSOS). It's extensible like a browser.

We'll cover new releases for those interested, but also talk about development in general: #Python, #webdev, SCMs, #DiffX, code review, etc.

#Diff files (whether #Git diffs, #Subversion diffs, even #CVS diffs) tend to be based on Unified Diffs.

Unified Diffs look like:

```
--- old_filename OPTIONAL_STUFF
+++ new_filename OPTIONAL_STUFF
@@ -oldpos,oldnumlines +newpos,newnumlines @@
- blah blah
+ blah blah
...
```

Anything outside of those blocks are ignored as "junk" by parsers.

This is where metadata for different Unified Diff-based formats tend to live.

And where all #DiffX parsing structure and metadata are placed.

Continuing with #projects, let me talk for a minute about #diffx!

Did you know there's no standard file format for #diffs? No, seriously. I mean, there are Unified Diffs, but that just covers the actual line changes. There's nothing for metadata, no consistency for filename encodings, nothing. It's a mess.

So we're working to solve that with DiffX:

https://diffx.org/

This provides #metadata, parsing rules, mutability, binary files.

All backwards-compatible with common diff variants.