mostly obvious.

Why we follow the Rails repo structure in Rails Event Store

Published on — originally on

Why we follow the Rails repo structure in Rails Event Store

A complete Rails Event Store solution consists of following gems:

The problem

Until recently, each of the gems lived in a repository of it’s own. That’s how you usually develop a gem and what majority of tools assume. Bundler for example in its release-helping Rake tasks provides a code for tagging git repo with gem version number for a RubyGems release.

Each gem in it own’s repository provides a separation and some gems like aggregate_root or ruby_event_store can be used completely on their own.

This split however has several drawbacks if you’re already a contributor or wishing to become one:

In short it was easier to start that way but it’s painful in the long run.

What Rails does

If you look at Rails repository you immediately notice the code layout:

It is also worth noting that each of the components gets the same version number as Rails release. It might be tempting to keep component versioning separate but it simpler from end-user perspective to refer to only one number (i.e. when reporting issues).

How we approached git migration

Being sold to the idea of monorepo we had to figure out “The How”. For sure we wanted to keep most popular repo alive (and base for others to be merged in).

We could think of 3 possible approaches:

git subtree merge

git filter-branch and pull –allow-unrelated-histories

git mv and pull –allow-unrelated-histories

For us, from contributor perspective, working file history is more important than preserving original commit identifiers. So we chose approach involving git filter-branch.

The migration involved running following snippet on each repo:


git filter-branch --index-filter \
  'git ls-files -s | gsed "s-\t\"*-&'"$SUB_DIR"'/-" |
  git update-index --index-info &&
  mv "$" "$GIT_INDEX_FILE"' HEAD

Finally each of rewritten repos where merged into destination one with following git pull modifier:

git pull --allow-unrelated-histories ../ruby_event_store

Sidenote: gsed stands for GNU Sed. BSD Sed available on MacOS caused me some trouble.

What changed for end users

All these changes were mostly for contributors and maintainers convenience. If you’re a happy Rails Event Store user you might be wondering if that change should be on your radar.

Last but not least Rails Event Store got new website. I encourage you to check it out and consider using RES to support your business.

You should follow me on twitter. DMs are open, feel free to reach out.