Skip to content

Latest commit

 

History

History
73 lines (54 loc) · 2.62 KB

4.4-anatomy-of-releases-repo-history.md

File metadata and controls

73 lines (54 loc) · 2.62 KB

Anatomy of Release Repo History

First, a picture!


.               <-- branch="master"
.                       The master branch keeps going, and every time a new
.                       release is made, those files are merged in to master.
|
*               <-- commit=07  tag="mdm/master/v2.1"
|\                      moved artifact.jar -> v2.1/artifact.jar
| \                     moved artifact.so -> v2.1/artifact.so
|  |   
|  *            <-- commit=06  branch="mdm/release/v2.1"
|                       added artifact.jar
|                       added artifact.so
|      
*               <-- commit=05  tag="mdm/master/v2.0"
|\                      moved artifact.jar -> v2.0/artifact.jar
| \                     moved artifact.so -> v2.0/artifact.so
|  |   
|  *            <-- commit=04  branch="mdm/release/v2.0"
|                       added artifact.jar
|                       added artifact.so
|      
*               <-- commit=03  tag="mdm/master/v1.0"
|\                      moved artifact.jar -> v1.0/artifact.jar
| \                     moved artifact.so -> v1.0/artifact.so
|  |   
|  *            <-- commit=02  branch="mdm/release/v1.0"
|                       added artifact.jar
|                       added artifact.so
|    
|   
|  
| 
*               <-- commit=01  branch="mdm/init"
                        Nothing really to see here.  This is just the commit
                        created to inaugurate the releases repository.

As you can see above, there are two types of commits. We can refer to these as release commits, and merge commits.

A release commit contains the files for one release version. When mdm update fetches dependencies for a project, it pulls one release commit.

The merge commits bring the files from one release commit into the master branch. The actual artifact files from the release are moved to a subfolder, so it's easy to have every release ever checked out in one working tree.

Master shows you the world

Checkout out the master branch gives you a folder per released version, each containing that version's files.

It's totally valid (and dang easy) to toss a git checkout master of an mdm release repo in an http server and call it your downloads page. You noticed that's where you got mdm from right? ;)

Fetch can deliver only what you need

The release commits can be fetched independently!

Since they don't accumulate each other's history, each release commit can be fetched independently, without needing to pull down any data from the other branches.

commit convergence

TODO can't decide if this deserves a whole page or just a section