The mono-repository

More and more organizations are experiencing the mono-repository solution for a while. Let me explain why I’am enthusiastic about that other way of thinking the version control and beyond, the way you’re designing, building and publishing your services.

Merge your repositories

Here’s a very straightforward solution for merging multiple repositories into one. The objective of this post is more about the why than the how, but I’m sure it can helps :p

Initial situation : two repositories

(will unfortunetalty be deleted at some time)

What I want to achieve : merge them to ends with this structure :

luxacode
\_libluxafor
 |_ contents of lcallarec/vala-libluxafor
\_ luxafor-cli
 |_ contents of lcallarec/luxafor-cli

Step 1 : Create the luxacode repository

This is the new repository you want to merge in.

mkdir luxacode
cd luxacode
git init

Step 2 : Import vala-libluxafor into libluxafor subdirectory

(you must have a local copy of the vala-libluxafor repository in ../vala-libluxafor)

mkdir libluxafor

git remote add vala-libluxafor ../vala-libluxafor/
git fetch vala-libluxafor
git merge vala-libluxafor/master
git remote remove vala-libluxafor

# Move manually hidden files, but don't move .git directory
git mv -k * libluxafor

Step 2.5 : Commit your changes :)

Step 3 : Import luxafor-cli into luxafor-cli subdirectory

(you must have a local copy of the luxafor-cli repository in ../luxafor-cli)

mkdir libluxafor
git remote add luxafor-cli ../luxafor-cli/
git fetch luxafor-cli
git merge luxafor-cli/master
git remote remove luxafor-cli
# Move manually hidden files, but don't move .git directory
git mv -k * luxafor-cli

Step 3.5 : Commit your changes :)

That’s done !

Why a monolithic repository ?

My own (almost) real project

Luxafor-cli is a command line tool that control a Luxafor device. It depends of vala-libluxafor, a library that expose an high-level API to handle an USB luxafor device.

These two projects lived in different git repositories, because they serve two different purposes. However, be noticed that Luxafor-cli code depends on vala-libluxafor code.

What was the main difficulties in working with these two repositories ?

  • When I build luxafor-cli, I usually add modifications to both repositories. I build a fresh shared object from vala-libluxafor to be compiled against luxafor-cli. Shared objects are made for that, aren’t they ?

  • Fortunately, as I’m a bit lazy, I automatized the process above. It adds new code that has to be maintained. Great, I like to maintain new code.

  • … and because I try do to the things right, I run the tests on both repositories - with my own-cooked unversionned-script (it can’t really fit in either repositories). It adds more complex step to the workflow. I’m happy to suffer.

  • What about git pull, git add, git commit, git push twice ? … fortunately, I don’t use branches :p

  • What about cd .. and cd - or working with many shells ? I can do lots of things at the same time. But don’t tell to my wife about it.

  • I can’t really complain if no one contribute to my project, the first build is a pain.

Back to the bias

These two projects lived in different git repositories, because they serve two different purposes

That’s my own thoughts when I created these two repositories.

First, why two different projects, because they serves different purposes, should live in different repositories ?

Because that’s the way we learned to use SVN or Git repositories, and we never questioned this assumption.

To be clear about the way I like to work with my tools : a tool is not supposed to drive the way I’m designing, building and publishing my services (except when it drives in the way I want to go)

In my own (almost) real project, I’m just isolating two projects, when one of them depends on the other. Looks like a scary idea.

It’s usually easier to focus on what separates two things - here, repositories, than what links them.

And obviously, they share a lot :

  • Same language : Vala
  • Common goal : provide tools to interact with a Luxafor device, with different purposes
  • Same tools, like make
  • Shared lots of common libraries (like LIBUsb)

One repository to rule them all

Moving to one repository was technically straightforward.

After a while, there was some wins :

  • luxafor-cli build, which depends on vala-libluxafor, is straightforward because the source code is always fresh and available. Flat is better than nested.

  • I can update all parts of the code, either vala-libluxafor or libluxafor without following a complex workflow. Simple is better than complex

  • When I push my code on github, Travis can run all the tests, for all projects.

  • I’m really happy to not use any dependency managers to manage my own private dependencies (yet another post coming out :p) Although practicality beats purity

  • I’ve got one Makefile to build all my projects.

Coming next

While frontiers disappeared, lots of new opportunities appeared as new questions arose.

New horizons can nudge you in unexpected directions…

We’ll see that in a next post.