Version control of schematics and source code
Most of it comes down to personal preferences.
I track everything I do for a project in Git. Especially since Git handles most types of files, even binary, sufficiently efficiently. (In stead of built-in Altium SVN nonsense)
One of my main reasons to do so is that my customers don't all feel Dropbox is safe enough and I need a back-up system that I can access across the world, with also some versioning context on most of what I do. So I set up a private Git server and encrypted backup system and it works a treat. Boards, Schematics, Code, Documentation, Reports, Manual Modifications, everything is tracked.
I would normally create a a Repository for Hardware, one for Software and one for Firmware if it is a large, potentially long-running project, but for small service projects, examples or little experiments I often put it all in one repository, since the resulting chaos won't be big.
In Git you can use sub-repositories as well to integrate the Firmware into the Hardware project or the other way around, even if they are separately managed repositories.
For the larger projects I also commonly use bug tracking systems to keep track of issues and resolutions, again for HW as well as SW, Mantis is a nice one that can be used for free.
For hardware revisions I generate Gerbers, or whatever have you, tagged with the Git Hash for that revision, those Gerbers then are the only discrete "old fashioned" versioned stuff in folders by R01, 02, etc. Since you don't want to regenerate them all the time, but they are resulting files so shouldn't be versioned in Git itself, really (because your design software should be deterministic with generating production content, or else ...).
If there's something interesting in R01 that isn't happening in R02 (or the other way around), you have two Git Hashes with which you can compare source files, no worries.
As a final note, one conceptual example of a project, would have a Hardware repository, which also hosts a "BoardPinout.h" file. This file is included as a remotely versioned file into the Firmware repository, which has a few interface definition files that get remotely included into the Software repository.
Meaning every time I change a few signals without modifying broad functionality the HW project "updates" the BoardPinout, which then can be updated and used in Firmware, and so on.
1) Its definitely worth versioning schematic/board files. Even if you can't track differences so easily, you have a clean way to revert to a specific hardware release if you have to work with an old device revision.
2) We have the following structure in our SVN.
/tag
/branch
/trunk/hardware
/trunk/software/firmware
If applicable with more sub-folders like maybe /Firmware and /ConfigTool for software and /mainboard and /daughterboard or something like that for hardware.
2) Tags are created from sub-folders not from the whole trunk, like Tag/Mainboard-v1.2.345. The hardware (namely the PCB) always contains the SVN revision in the silk screen print or in copper to have a direct reference.
4) Dependencies between hardware and firmware can be complex. IMO it doesn't make that much sense to deal with it on the repository level except leaving useful comments on commits.
Consider encoding hardware changes using spare I/O pins. Something like using 4 pins to encode 16 different hardware versions. We also used a single ADC input with different resistance values to encode versions. This way the software can "know" on what hardware it runs and change/disable/enable specific features.