3 ms·

We're transitioning from a SVN monorepo to Git. We've considered doing a kind of best-of-both-worlds approach. Some core stuff into separate libraries, consume

We're transitioning from a SVN monorepo to Git. We've considered doing a kind of best-of-both-worlds approach. Some core stuff into separate libraries, consumed as nuget packages by other projects. Those libraries and other standalone projects in separate repos. Then a "monorepo" for our main product, where individual projects for integrations etc will reference non-nuget libraries directly. That is, tightly coupled code goes into the monorepo, the rest in separate repos. Haven't taken the plunge just yet tho, so not sure how well it'll actually work out.

dezgeg 2y ago
In my experience this turns to nightmare when (not if, when) there is need to make changes to the libraries and app at the same time. Especially with libraries it's often necessary to create a client for an API at the same time to really know that the interface is any good.
- magicalhippo 2y ago
  The idea is that the libraries we put in nuget are really non-project-specific. We'll use nuget to manage library versions rather than git submodules, so hopefully they can live fine in a separate repo. So updating them at the same time shouldn't be a huge deal, we just make the change in the library, publish the nuget package, and then bump the version number in the downstream projects that need the change. Ideally changes to these libraries should be relatively limited. For things that are intertwined, like an API client alongside the API provider and more project-specific libraries, we'll keep those together in the same repo. If this is what you're thinking of, I'd be interested in hearing more about your negative experiences with such a setup.
adastra22 2y ago
...just curious, what's your line of work where you're still using SVN?
- magicalhippo 2y ago
  Company makes B2B software. Our main product is a traditional Win32 application with over 25 year old code in production, though most of it is much more recent. SVN worked well for us, being a relatively small team until recently, so no real need to change until now. The primary driver for the move to Git has been compliance. We just can't have on-prem servers with critical things like code anymore, and there's effectively just one cloud-based SVN offering that had ISO27001 etc. So incentive to move to Git just got a lot stronger.

dezgeg 2y ago

In my experience this turns to nightmare when (not if, when) there is need to make changes to the libraries and app at the same time. Especially with libraries it's often necessary to create a client for an API at the same time to really know that the interface is any good.

magicalhippo 2y ago
The idea is that the libraries we put in nuget are really non-project-specific. We'll use nuget to manage library versions rather than git submodules, so hopefully they can live fine in a separate repo. So updating them at the same time shouldn't be a huge deal, we just make the change in the library, publish the nuget package, and then bump the version number in the downstream projects that need the change. Ideally changes to these libraries should be relatively limited. For things that are intertwined, like an API client alongside the API provider and more project-specific libraries, we'll keep those together in the same repo. If this is what you're thinking of, I'd be interested in hearing more about your negative experiences with such a setup.

adastra22 2y ago

...just curious, what's your line of work where you're still using SVN?

magicalhippo 2y ago
Company makes B2B software. Our main product is a traditional Win32 application with over 25 year old code in production, though most of it is much more recent. SVN worked well for us, being a relatively small team until recently, so no real need to change until now. The primary driver for the move to Git has been compliance. We just can't have on-prem servers with critical things like code anymore, and there's effectively just one cloud-based SVN offering that had ISO27001 etc. So incentive to move to Git just got a lot stronger.