What do you think about SCM-based (subrepositories in mercurial, submodules in git) dependencies management?Is it definitely a good way of managing dependencies? Or definitely bad way?Should I prefer some build system (ant/phing/rake) over subrepositories?Some particular example for you to have a context:I have several web applications that share across reusable components, say jquery plugins.
Subrepositories (submodules) as a dependency tracking solution - yes or no?
git;mercurial;dependencies
If you have the option, then go with a dedicated tool instead of using the SCM for this. I've written about this on SO, but the argument boils down to coupling, in particular overly tight coupling. Flexible software development is all about avoiding tight coupling unless it's really needed and both Mercurial subrepositories and Git submodules introduce a very tight coupling.In addition, subrepos/submodules introduce extra complexity in the daily workflow. If people are already familiar with the SCM, then this might be acceptable. But I've seen many organizations where they tries to introduce Mercurial and subrepos at the same time  I consider that a mistake since it just makes everything seem extra complicated.The Mercurial wiki has a set of recommendations for how subrepos should be used. These include the use of a thin shell repository. This avoids coupling the components together. You can work in either subrepo as needed and push/pull to update them. Once in a while someone (maybe a build engineer, maybe a continuous integration server) will test new configurations of the components. If they pass tests, then a new commit is made in the shell repository so that people have a new base to use for their work.