Git submodules vs Nuget packages [closed]

Question

Our team has experimented with git submodules for some core CRUD functionality shared by most of our products. We have also successfully used Nuget packages (self-hosted now) for some common utilities.

Our core functionality changes often enough that keeping submodules properly committed is proving to be more of a chore that we expected. I am considering moving the core functionality from a submodule to a Nuget package but am wondering if the frequent updates to the packages would be even more of a pain in Nuget.

Does anyone have any experience and guidance as to what other challenges I might encounter before making this slightly intrusive change to our architecture and process?

Rident

SourceTree will automatically detect that submodules contain uncommitted edits and prompt you to commit them any time you commit the parent project. – Samaritan

I wonder what you end up with? We think of going from Nuget to git submodules.I don't like that our nuget packages do not contain pdb files(to decrease size).Debugging is complicated. How it would be nice to have all projects in a solution that you can step into when debugging. Another potential problem is a storage size. We use sonatype nexus and need to have nearly indefinite retention policy for packages as some packages may be required if they're 10 years old. Because of these package cross dependencies nuget archives/packages will have repeated dlls. Afraid it would require lots of space – Betel

Answer 1

As with anything, it depends. Have you considered using a separate CI package repository where every commit to the core module produces a CI package?

The biggest challenge imo is package versioning, as NuGet doesn't support SemVer yet to its full extent (e.g. pre-release versions + build number).

EDIT: nuget.org now supports SemVer 2.0 package versions. See this spec: https://github.com/NuGet/Home/wiki/SemVer2-support-for-nuget.org-%28server-side%29

Use SemVer properly. You usually don't know the released version number upfront, so your CI package version continues from the latest stable release. CI packages as such are to be considered pre-releases.

E.g.: 2.2.0-CI201209140650 (which is a CI build taken on 2012-09-14 at 06:50 for an upcoming 2.2.0 release) <-- note: this release version can still change, but there's always going to be an update path.

If you adopt SemVer v2.0.0, you can even adopt the following example: 2.2.0-CI.2012.09.14.06.50.

Important note: nuget.org (and by extent any other NuGet server/service out there such as MyGet or VSTS) does not support multiple package versions differing only by build metadata!

This has worked for me using these constraints (and some proper TeamCity build configurations). So in short, these are the hassles:

• proper versioning
• reminder to select proper package source (keep your CI pkgs separate from pre-releases and releases, although technically your CI package is versioned as a pre-release)
• upgrading from a CI pkg to a pre-release might be an issue if the pre-release tag is string-sorted higher than "CI" (e.g. "Alpha"). In this case: uninstall-package "CI" followed by install-package "Alpha".

Hope this helps!

Babbittry

does Nuget still not support proper SemVer ? – Courtneycourtrai

nuget.org supports SemVer 2.0 as of recently. Will update my response accordingly. See this spec for details about how nuget.org supports semver 2.0: github.com/NuGet/Home/wiki/… – Babbittry

Answer 2

I prefer using submodules over Nuget packages for frequently changing internal libraries. Here's why:

• Merging: If several developers make changes to the same library at the same time, with submodules, these changes can be merged. With Nuget packages, obviously there's no concept of merging.

• Less wait: With submodules, you push, and then pull with whatever repo you need to use the submodule in. Usually a few seconds. With Nuget you must wait for the package to be be published, typically after your CI process completes.

• Versioning clashes: Again, if several developers make concurrent changes, they may increment the Nuget version # to the same one, despite their changes being different. How much of a pain this is to address depends on your CI process.

• Debugging: Since Nuget packages are compiled, you can't step into their code.

• Can make changes in "client" repos: Sometimes it's easiest to flesh out the details of library changes while working on client code that will use the library. With submodules, this is possible. Of course, this is no substitute for test coverage.

Pustulant

Add one more point - Submodules supports debugging while NuGet doesn't – Fab