Working with Mircosoft Office Sharepoint Server 2007 (standard edition) what is the best way to place a site collection being developed under version control? We're using Subversion for all our other (non-sharepoint) projects but I'm just not sure how to approach MOSS.
What needs to be placed under version control to ensure we have everything we need to rebuild the Sharepoint Environment?
The question is sort of vague has you do not mention how you develop it. If you're just doing out of the box modifications on a site collection via the interface you have available in sharepoint it sounds like you need to do some kind of "backup". I don't think you can export a site collection as a template :P
If you're doing actual development, coding features that do site provisioning, web parts for that, custom page layouts and whatnot, I would suggestion copying the structure you have in the /12/ hive on your sharepoint in your visual studio. Place all the artifacts you have in the right folders in your solution and that makes it very easy to deploy, either just by copying and calling some stsadm commands or by making a new manifest.xml file and a .ddf file which you can then add to your solution repository on your sharepoint installation.
Adding to mortenbpost, in order to store the site structure in source control you would need to have its creation in code. For example a feature receiver that creates the site collection as it is first supposed to exist when the feature is activated.
There is no way to take a site structure from MOSS and put it in source control. When the site goes live users are going to add content which you won't want in source control anyway.
What you're asking is can you version control an entire SharePoint site collection?
The only way I know you could do that with some ease, is probably with Team Foundation Server http://msdn.microsoft.com/en-us/library/cc948982.aspx
They claim that you can version control custom SharePoint products, and I'm assuming they mean the database portion of that as well. I would think that would be the most future proof route.
Currently what we do at my work, is we have a Subversion server, in which we use a Visual Studio plugin called AnkSVn, when we're developing custom webparts, and solutions that may contain many workflows, and webparts.
We don't currently do any versioning on the content database of SharePoint, although I'd love to try TFS, and see if that would work. We use the stsadm tool as developers to backup the development server before we're doing big changes, and we have periodic backups of the SharePoint databases by our DBAs.
Restoring the content database will put back all the previous content, workflows, sites, templates, features, of a SharePoint site collection, from my experience.
Source control isn't just backup and source control isn't necessarily meant to be a backup solution. It's all about being able to do diffs of text files, collaborative development, branching and merging.
If the goal is disaster recovery, then get an empty server and start enumerating all the bits you had to use to rebuild the server and it's contents. Back up those bits, using differential backups, etc.
If the goal is to enable collaborative development, branching and merging, n-level undo for code artifacts, then carefully examine which code artifacts are binary and which are text. You won't get as much benefit from putting binary artifacts in subversion because you won't be able to merge or get diffs.
Also in the case of sharepoint, any modification you make to a website after you import the template will be difficult to version because those bits are stored in some hidden proprietary format inside the built in sql server. Not all of the components of your sharepoint solution are going to be on the filesystem where subversion really shines as a source control tool.
Building upon what is said above: