To me, it's a decision between single repo and repo per client. As you also said, the branch per client idea doesn't seem reasonable to me (too complicated, no advantages).

Now, I've been working with both approaches, and the advantages of a single repo over multiple repos are to me:

• Ease of development: one checkout gets all the clients, no need to set up 20 workspaces (git submodules could also help)
• Tags and branches hold all the code: there's only one v1.0. If I understood it correctly, you use the same version number across all clients, so that's an advantage for you.

You had concerns about customers still being on the 1.x branch, while others are already on 2.x. I suggest using branches for this. While your master branch contains the 2.x code, you could still work on the 1.x code on another branch, and start releases from that one.

In one project, we called this "generations". Branch generation/1.x was worked on, and we started bugfix, release or even feature branches from it. You can always cherry pick (SVN: "merge") commits between generations, and if one customer moves to 2.x, you could move his directory over to master (or whatever generation is appropriate).

To me, the major concern would be scaling (or repo size): if the number of your clients grows, or your codebase takes lots of disk space, a single repo might get hard to handle.

To me, it's a decision between single repo and repo per client. As you also said, the branch per client idea doesn't seem reasonable to me (too complicated, no advantages).

Now, I've been working with both approaches, and the advantages of a single repo over multiple repos are to me:

• Ease of development: one checkout gets all the clients, no need to set up 20 workspaces (git submodules could also help)
• Tags and branches hold all the code: there's only one v1.0. If I understood it correctly, you use the same version number across all clients, so that's an advantage for you.

You had concerns about customers still being on the 1.x branch, while others are already on 2.x. I suggest using branches for this. While your master branch contains the 2.x code, you could still work on the 1.x code on another branch, and start releases from that one.

In one project, we called this "generations". While there was a master, branch generation/1.x was also worked on, and we started bugfix, release or even feature branches from it. You can always cherry pick (SVN: "merge") commits between generations (or master). Finally, if one customer moves on to 2.x, you could move his directory over to master (or whatever generation is appropriate).

To me, the major concern would be scaling (or repo size): if the number of your clients grows, or your codebase takes lots of disk space, a single repo might get hard to handle.