Many small scripts, one repository or multiple?

Question

A co-worker and myself have run into an issue that we have multiple opinions on.

Currently we have a git repository that we are keeping all of our cronjobs in. There are about 20 crons and they are not really related except for the fact that they are all small python scripts and essential for some activity. We are using a fabric.py file to deploy and a requirements.txt file to manage requirements for all of the scripts.

Our issue is basically, do we keep all of these scripts in one git repository or should we be separating them out into their own repositories? By keeping them in one repository it is easier to deploy them onto one server. We can use just one cron file for all the scripts.

However this feels wrong, as the 20 cronjobs are not logically related. Additionally, when using one requirements.txt file for all the scripts, it's hard to figure out what the dependencies are for a particular script and they all have to use the same versions of packages.

We could separate all of the scripts out into their own repositories but this creates 20 different repositories that need to be remembered and dealt with. Most of these scripts are not very large and that solution seems to be overkill.

A related question is, do we use one big crontab file for all cronjobs, or a separate file for each? If each has their own, how does one crontab's installation avoid overwriting the other 19? This also seems like a pain as there would then by 20 different cron files to keep track of.

In short, our main question and issue is do we keep them all closely bundled as one repository or do we separate them out into their own repository with their own requirements.txt and fabfile.py? We feel like we're also probably looking over some really simple solution. Is there an easier way to deal with this issue?

Answer 1

Unless there exists a specific reason for you to think that each one of them deserves an invidual repo (Will they grow a lot? Probably not!) it seems more reasonable to put them all in one repo, and save yourself the trouble of cloning all of them from 20 repos.

Keeping each one in a separate repo seems like the path of creating a problem where a problem does not exist.

Don't create extra work for yourself (and others).

Answer 2

Unless there is a really good reason for the split (performance; overwhelming organizational/security concerns etc..) my instinct is to keep source documents together in the same repository.

Splitting systems out into separate repositories generally creates barriers that inhibit reuse; since reuse is just about the only way that an organization has to amortize the cost of development, anything that gets in the way of reuse is ipso facto a bad thing.