On 02/02/15 09:09, Vladimir Panteleev via Digitalmars-d wrote:
2c. Versioning
Git stores the exact commit of each submodule in the parent repository.
So, if you make a commit in orchard/fruit/, and run `git status` in orchard/,
git will show you that the "fruit" submodule has been modified.
Most importantly, this means that any breaking change in the "fruit" library
will never affect existing projects which use it, since they will continue to
use the registered commit which was known to work.
This gives you dependency versioning with commit granularity - you can hardly
ask for something better - all without messing with configuration files.
This is both a benefit and a problem.
It's a benefit to the developer, who can specify exactly which version of the
dependency they want used. It's not necessarily good for the downstream user,
because it requires that the developer actively maintain the dependencies.
Scenario: a dependency has a security hole that gets patched. If the dub
package is updated, all applications using that dub package will automatically
have that update available next time they are built. With git submodules, the
developer has to recognize that update has happened and tweak the git submodule
in the master project, and others downstream have to realize that has happened.
Git submodules are great for precise control of dependencies, but there are
circumstances where it's preferable for upstream to be able to release new
versions without them being filtered in this way. I'd readily use git
submodules in scenario where I controlled all of the code (including what was in
the submodules), but not where I had external dependencies.
2d. Git vs. Dub
Unfortunately, the above-described approach is not compatible with Dub:
- Dub packages are generally expected to have their source code in a "src"
subdirectory, although you can set the source directory to "." in the
configuration file.
Actually, I think it's 'source'. But either way, it's just enforcing a good
layout practice, that can be reworked with the config file. There is however
some benefit to imposing a standardized project layout.
- When cloning repositories, dub does not preserve the repository's directory
name (so e.g. fruit will be cloned to ~/.dub/fruit-1.0.0/).
Necessary in order to maintain multiple versions of a package in order to
satisfy different applications' dependencies, surely? You have a similar
situation with different versions of shared libraries installed on any UNIX system.
