It would seems a new fashion has come to the world of software engineering, which anyone is expected to have an oppion about. The so called mono-repo talk.

As with so many other cases there seems to be multiple definitions flying around and not asserted definition of when you have a mono-repo, but let me try to share some thoughts.

• A repository is a place, where sourcecode (and potentially other stuff) is associated with software development is stored.
• A mono-repository is when all the sourcecode produced in a company is manged in a single repository.
• A Single-server respository (strategy) os whenn all sourcecode is manged in a single (git) server, but every project has its own repository.

On the multi (git)server, multi repository setup…

I don’t like it.

Github is quite a fantastic service for source code management and hosts a suite of wonderful tools which can help you manage the development, tracking issues and much more.

One of the fun things is the github activity dashboard located on your personal frontpage which shows how much you’ve done.

I’m sure it’s mostly a fun thing and it allows you to sort of get an idea of it the account is dead or alive. Some seem to have pride in having a green carpet showing long periods of continuous activity.

Switching to Hugo caused a major change in the workflow behind the site.

Wordpress comes with a full-featured backend which allows you to manage basically your entire website (if it’s Wordpress powered), but Hugo don’t. There’s no-backend admin site nor an webeditor to create and manage your posts. It doesn’t bother me. It’s a completely different workflow and I’m starting with a rough minimum flow initially untill I get a bit more expirence running Hugo.

I’m sorry but sometimes I really don’t get why even seasoned developers doesn’t learn the art of the commit message in version control system. All too often I’ve come across check-ins where the entire commit message just reads “bugfix”, “change”, “oops” or something just as mindless.

The effort of writing a useful message compared to the potential benefit seems to be one the best ratios - but of course the pay-back is usually some time away - too bad. Once you work on the same code for years - or even better inherit code from others, you’ll quickly learn to appreciate anyone who used more than 10 seconds on composing a thoughtful message for the future.

Most developers (and certainly professional shops) working with software- or webdevelopment has understood the ideas behind sourcecode version management - no matter if they choose to use cvs, subversion, git or any of the other fine systems available. How developers use these systems, can provide an easy insight into who is the dummy, the average and the great developer.

When to commit

One of the first distinguishing signs is what they commit - is the version management system used as a backup tool or as a version tracking tool. Some seem to think, you should end the day by committing all your sourcecode (no matter which state it’s in). This is really bad sign. Others commit whenever a new file is finished and thought ready to use - which is slightly better. Others again commit once - just before a new release - and has the commit contain each and every change since last release.