> Git has lockin, but you don't hear of people avoiding branches in case they need to move to perforce.

Replace Git with SVN in the comment above.

Also replace Perforce with Git in the comment above.

Then you have a viable argument and a story of mine that actually is a case of exactly that - back when project management for certain projects was done primarily in SVN, there was the expectation to stick to the popular way of laying out repositories, with folders for trunk, branches and tags, a bit like the example here: https://stackoverflow.com/questions/2611237/subversion-repos...

Of course, you didn't really need to do it that way and certain other projects explored other options, such as having features under the root of the repository, like "/ISSUE123" or something like that.

Well, as time passed, it became apparent that SVN just wouldn't cut it (TortoiseSVN was such nice software, though) and that the projects would need to be migrated off of SVN and into Git, to import them into GitLab/GitHub or elsewhere. Those projects all still being in development and having the need to be trace back changes to particular feature requests/issues meant that all of the revision history would also need to be moved over.

The problem with most of the migration scripts, however, was that they broke when you had a non-standard layout and as a consequence of that, you simply couldn't finish the import process and were stuck on SVN. Back then I actually resolved it by rewriting the history of those repositories into the standard format, but it was just a massive waste of time and a headache.

Alas, a sentence like this would absolutely be false:

> SVN has lockin, but you don't hear of people avoiding non-standard repo layouts in case they need to move to Git.

So yes, despite there being certain features and the ability to do something, that doesn't immediately mean that you should jump right in and use them! I might also have a few horror stories about Git submodules, or maybe even using Git LFS with synchronized Git repositories across GitHub and GitLab (of course, the LFS contents weren't sent properly, so no binary assets were mirrored), as well as other such problems.

If you can, stick to a stable, boring and predictable set of core features in any software package.

In my career I have repeatedly seen people regret ignoring portability. Some times because the old supplier went out of business. Some times because CEOs had a big fight. But mostly out of carelessness. I do not really care as it has been a source of a lot of my work. But it is very important: Be portable.

What happens if you get kicked off AWS?

What happens if Oracle goes broke?

What happens if Sun decides it will not let Java run on MacOS?

Etcetera. Often there is limited possibility for portability (people often thought programming in Java made things portable - they were partly right) but each element of lock in you allow must have a very good reason.

In my experience it is usually not a consideration.