We intend to use Mercurial for version control of our WordPress website development.
The development model in WordPress dictates that development usually occurs in a couple of sub directories off the main root for plugins and themes while the main root is subject to change via WordPress version updates and doesn’t need to be version controlled.
My question is if this situation is best managed with a repository located at root with a hgignore to remove the main WordPress code from VC, with just the previously mentioned sub directories under control OR a couple of sub repositories rooted in the directories where the development occurs and a wrapper parent repository to join them together?
What are the pros and cons of each approach and the effect on deployment?
With the second approach (sub repositories) when you done the initial pull on a new server would the development directories be created in their correct position within the WordPress tree?
As a general practice, I would highly recommend version controlling only the source code that you intend to maintain. Using Git, I’ve previously done 1 repository per theme/plugin with good results. With the exception of parent/child theme relationships, WordPress themes are more or less entirely independent of one another. Since each theme is logically separate, it also makes sense to version control it as a separate entity.
It’s also very likely at some point you will want to push updates for one theme, but not others. Having separate repositories makes it easier to check-in changes for all your different themes, but only publish changes for one at a time. While you can achieve the same result using branches, if you have more than a handful of themes, it can get very complicated.
Certainly, it comes down largely to what’s comfortable, but in my experience managing an install with 50+ themes, that was just what worked easiest.