Setting up the ideal multiple repository Drupal Site version control with a DVCS
A general workflow when it comes to Drupal is to clone the core repository and use it as the base for your local repository. Then, you'd create a separate branch specifically for your custom site, so as not to disturb the core branches.

Next, you'd add each module you'd want to use as a submodule off of this branch: this allows you to track specific versions of modules while still having the flexibility to easily upgrade them in the future.

Then, you'd set up an exclusion plan for user-generated content and your settings file. Generally, this would include:


sites/SITENAME/files
sites/SITENAME/settings.php


Finally, when you want to upgrade third-party content:


With core, you'd pull the latest changes and rebase your custom branch
With contrib, you'd navigate to the specific module's directory, pull the latest changes, and commit the new submodule hash to your custom branch.


The problem is, this works really, really well... if you use git. As Drupal has standardized on git, it's just a matter of linking to the correct drupal.org repositories and pulling when necessary.

If you're using a different VCS, submodules aren't really going to help unless you want to spend the time to convert each and every drupal.org repo for the modules you're using to whatever VCS you want to use. That's a lot of work, especially for a one-off project.

Alternatively, you could follow the above workflow, but instead of setting up a repo for each and every contrib module, you could set up one private repository called contrib, and manually add updates to contrib there. This way, you can keep contrib code separate, but you spare yourself having to maintain potentially dozens of custom repositories that do nothing other than duplicate drupal.org repositories.