Hi, I'm Dominik Schwind, friend of the internet. Here is /now.

There are a couple of ways you can follow me around on the internet. The prefered way would probably be with a feed reader - here is my RSS feed.

If you need more direct access, you can follow me here with Mastodon or similar sites: @dominik@nona.social. You can also follow this blog via @dominik@lostfocus.de.

January 25, 2013

Warning: If you don’t know what version control systems are and why one would need it, you can stop reading. This is going to be gibberish to you.

svn has externals and for git there are submodules – a way to include content from external sources in your source code. And if that’s not how you want to do it, there’s always a way to get code from a vendor or some central code repository when running a build script.

It is really convenient and if it works, it’s magic – you don’t have to host your own crap, if the remote library1 follows Semantic Versioning you might be getting bugfixes without having to think about it and everything is peachy.

And yet, I am wary about it: way too often I have seen repositories just vanish into thin air2 and even though local backup copies where available, it took time and effort to get together all the necessary ressources to work on a project.

So, whenever I’m the one who can decide or at least comment on decisions like that, I’ll very much vote for including all the code that is necessary to run a piece of software in one repository.

  1. Or whatever else it might be. 
  2. Yes, even internal ones. Because they looked useless and took away too much space.