C1 Apps -- what to put in source control?

Topics: General
May 27, 2011 at 9:22 PM

Hi all,

I dumped my Composite C1 app into source control, and I noticed when I make commits, there are random locations where lots of files go missing (I'm assuming related to cache).  Do you have a list of directories that should be excluded when using source control?  For example off the top of my head App_Data/Composite/ApplicationState or App_Data/Composite/Cache -- are there more?  Should I be ignoring these entire directories or just certain subdirs?  

Are there any documents that explain what each directory under App_Data is for exactly?  For example. I am using the SQLDataProvider package, was wondering if now I can ignore the DataStores dir.


May 28, 2011 at 11:24 AM
Edited May 28, 2011 at 1:44 PM

No official documents, but it has been discussed earlier http://compositec1.codeplex.com/discussions/238657

There can be no definite list of directories to include or exclude since its all up to the single developer or project what makes sense to put in version control or not. Are you for instance defining datatypes using the "wysiwyg" editor or code first? With code first approach you would version control these code files, while with the "wysiwyg" editor its a bit more tricky since its now defined as configuration information. The same goes for functions and templates. Source of them are in xml files that are easy to version control, while the information about them in the system are defined as configuration information. 

The datastore is unfortunately not only used to store user-content, which you would normally not version control, but also configuration related data for how the CMS is configured, which you DO want to version control. Using the SQLDataProvider you therefor end up with information in the database you would like to version control, and for that you would have to look into ie. Redgate SQL Source Control. http://www.red-gate.com/products/sql-development/sql-source-control/

I'm sorry not being able to come with a clear answer, but as i said in the beginning it much depends on your specific needs. I have long knowledge and experience of version control and would able to guide you more if you outlined more of your requirements.

 - Are you one or more developers?
 - Do you want to be able to install Composite C1 from scratch, checkout newest version of your source and have a working copy of your site up and running?
 - Are you doing Continuous Integration from version control?
 - Does every developer have their dedicated development server or are you using a single shared development server?
 - Do you use code-first directly from Visual Studio or do you only rely on the "development environment" inside C1 Console? 

May 30, 2011 at 7:38 PM

First off sorry for taking so long to reply, been away:

Here are the answers to your questions:

1. I am the only developer but there could potentially be more.  The site I am working on is not very complicated, most of the logic is done via XSLT (ie I am not building anything).  

2. Yes

3. Not really, like I mentioned nothing about this site is complex to require anything being built.  At most people will just be committing XSLT/CSS changes, 

4. Everyone will have their own, but there will be a staging and production environments that I would like to deploy to by just doing a fresh install/checking out my app into.

5. Thus far I've just been using the C1 console dev environment.

Ideally what I would like is when I'm first setting up the staging/production environments, I would do a fresh C1 install and somehow check out my app from source control to get it up and running for the first time.  But typically just have myself and other developers commit to that repository.

May 31, 2011 at 1:36 AM


We're doing our first Composite C1 project and we're getting our heads around how to get the solution under source control. We're not using SQL Server, so just plain XML files for the data store (we're planning to use Azure, so no Azure SQL Server as yet).

We've had some problems around versioning the "DataStores" folder, which seems to contain all the XML data files. The problem is that whenever a developer does a check in, some of the XML files have usually changed, which causes merge conflicts. What we have decided to do is to create a "DataStores Master" folder under source control, which contains the latest accurate snapshot of the DataStores folder. We have removed the "Datastores" folder from source control, which allows everyone to have their own working copy of the database. With this approach it is a manual and conscious decision to update the Master folder, which only one person can do at a time. This works for us because most of the development we're doing is in .NET custom controls, which doesn't affect the data store. Not sure what the best approach would be if the content is dynamic and needs to be edited often by multiple people...


May 31, 2011 at 7:40 AM

remember that source control is not all or nothing, you can choose to only include some of the files in DataStore. The following composite specific folders is what i've had good experience of source controlling. And then of course you include your folders with css, javascript, graphics and stuff. 

  • root
    • web.config
    • global.asax
  • root/App_Data
    • Xslt
    • PageTemplates
  • root/App_Data/Composite
    • Composite.config
    • Configuration
    • DataMetaData
    • DynamicTypeForms
    • InlineCsharpDFunctions
    • TreeDefinitions
  • root/App_Data/Composite/DataStores (if using file based datastore) - all except
    • IPage, published and unpublished in all languages
    • IPagePlaceholderContent, published and unpublished in all languages
    • IUserConsoleInformation
    • IFlowInformation
  • root/Frontend/Styles
    • VisualEditor.common.css
    • VisualEditor
  • whatever extra files that you make custom modifications to
May 31, 2011 at 5:03 PM

This is extremely helpful.  Thanks a lot!

Jun 3, 2011 at 2:06 AM


Thanks also for the information. We're using Team Foundation Server for source control and one of the limitations of TFS is that, for Visual Studio Web Site Projects under source control, it is All-Or-Nothing. We've implemented some client-side cloaking for the folders (such as the caching folders) to work around the fact that you can't ignore folders for this type of VS solution. It's a bit messy but it works...

Are there any plans to make Composite C1 available as a Web Application instead of a Web Site? Is it possible to convert a C1 Web Site to a Web Application?

Thanks for the help...


Jun 3, 2011 at 9:30 AM

We are not planning to change from web application to web site -  we initially prioritized being able to change asp.net code and reload a page without recompiles, but nowadays we very seldom touch asp.net file code so the decision to run as a website isn't carved in stone.

You could try to convert to a web application and see if this enable a good Composite C1 integration with TFS - I would be surprised if it did though. As far as I know files in TFS must be explicitly checked out for editing and files that Composite C1 create and update at run time would not be added to / checked out of TFS.

Perhaps this could enable a good TFS integration; all file IO done by Composite C1 is handled by a plug-in and it should be feasible to write a file IO provider which add new files to TFS and ensure existing files are checked out when updating. My guess is that you could keep the web site project as is and focus on a TFS aware IO provider for Composite C1. Let me know if you would like to go in this direction and I post plug-in details.

Sep 5, 2011 at 10:55 AM

Hi guys

Our team has managed to convert 2.1.1 web site to web application project, but I'll open another discussion regarding