Control Your C1 CMS Versions

Although you can version control C1 CMS, there is no universal approach to it. It depends on what you do in C1 CMS and what you want to version control.

Read how to version control C1 CMS Website files with Mercurial

For example, if you are more on the ASP.NET web development side with Visual Studio as your primary development tool, you might be more interested in tracking changes to your C# code which can be easily singled out among C1 CMS's original files. Besides, you may want not to version control changes to page content in this case.

If you do a lot of XSLT development and create your own data types and XSLT functions in C1 CMS's administrative console, you rely more on how the system handles changes for you at the low level. So the task of version controlling these changes might be a bit tricky at the first sight. However, if you know what gets affected and where, you can properly configure your checkins and checkouts.

In addition, if you use an SQL Server database as C1 CMS’s data store rather than flat XML files, you will also need to track changes in the database.

In general, you can split the C1 CMS's files into 3 groups according to the changes made to them:

• Unchanged files which are the files the system does not change normally and you usually do not change them either directly or via the GUI (unless you come up with some hacks and tweaks).
• Files changed by the system while you create or change something in the GUI.
• Files created and changed by you - directly, for example, CS files in /App_Code, or CSS files in /Frontend.

It is up to you to choose how to handle unchanged files. Normally, you will not version control them unless you change something about them. And the files directly changed by you are what you will surely version control.

As to the files changed by the system for you, you should distinguish at least two subgroups thereof:

• Temporary and cache files you normally will not want to version control
• Essential system files you most likely want to version control

In the sight of all this, we can only suggest the most general guidelines to version controlling in C1 CMS, which you should adjust to your specific setups and needs. We suggest you should version control in C1 CMS:

• 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 an XML-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
• and any other files you make changes to.

C1 CMS File and Folder Quick Reference

To make the picture clearer, here is a quick reference for major folders and files in C1 CMS. It might help you fine tune your version controlling.

Root Files and Folders

ASP.NET folders such as /App_Code/ or /App_Global/ may not be on your setup. If they are, you will want to version control them.

/App_Data/: This folder contains a number of subfolders and files that need specific handling: See below "Folders in /App_Data/".

/Bin/: This folder contains unchanged binary files of C1 CMS as well as of some packages you might install.

There is also Composite.generated.dll here, re-compiled by the system every time some changes to data types are made. You do not want to version control this file.

/Composite/: This folder contains unchanged system files. If you do make changes to these files (for example, in /Composite/Localizations/), be sure to version control them.

/Frontend/: This folder contains unchanged system files. However, this is where you can keep your own CSS, JS or image files. In this case you should decide for yourself what to version control here. If you make customizations of Visual Editor, make sure to version control /Frontend/Config/VisualEditor/common.xml and any other related files as well.

/Renderers/: Here are unchanged system files that render pages, media files etc. Unless you make some tweaks in C1 CMS by changing these files, you do not need to version control them.

/default.aspx: This is an unchanged system file.

/Global.asax: If you change this file, do version-control it.

/Web.config: You are very likely to change this file, so do version-control it.

Files and Folders in /App_Data/

Now let's look into /App_Data/:

/App_Data/Composite/: This folder contains a number of subfolders on its own, each of which needs a special treatment. See below "Files and Folders in /App_Data/Composite/".

/App_Data/Media/: This folder contains all the media files you upload to the Media Archive (on a clean installation it might be empty). Normally, if you do not version control website's content, you do not need to version control the media files either.

(You can use Composite.Tools.PackageCreator to export all the files from the Media Archive to a package. See below "C1 CMS Tools".)

/App_Data/Page Templates/: This folder contains the page layout templates which you will most likely change quite often. You should version control this folder and all its files. Please note that the meta information about templates you create in the GUI is stored in other places, too.

/App_Data/Xslt/: This folder contains the templates of the XSLT functions you create in the GUI. You should version-control them. Please note that these are only templates. The information about functions themselves, their input parameters and function calls is kept elsewhere.

Files and Folders in /App_Data/Composite/

And now let's see the inside of /App_Data/Composite/.

/App_Data/Composite/ApplicationState/: This folder contains application state data. You don't need to version control it.

/App_Data/Composite/Cache/: This folder contains cached and temporary files. You don't need to version control it.

/App_Data/Composite/Configuration/: When you create something in C1 CMS it will most likely be added to one of the Dynamic Data Provider's file (e.g. DynamicXmlDataProvider.config). You need to version control it.

/DataMetaData/: This folder contains metadata of datatypes. You should version control it.

/DataStores/: If your data store is XML-based, this is where data is stored - in the XML filed. (For SQL data stores, please see "SQL-Based websites".)

Most files in  thisfolder must be version control. The pages of your website (structure and content) are stored in Composite.Data.Types.IPage_xxx.xml and Composite.Data.Types.IPagePlaceholderContent_xxx.xml (published, unpublished, language-specific). Nomally, you do not need to version control these. You do not need to version control Composite.Data.Types.IUserConsoleInformation_Published.xml and Composite.Data.Types.IFlowInformation_Published.xml, either.

(If you need track changes to the pages, we recommend using the Composite.Versioning.ContentVersioning package. You can also use Composite.Tools.PackageCreator to export all the pages in C1 CMS to a package. See below "C1 CMS Tools".)

/DynamicTypeForms/: If you customize data forms ("Edit Form Markup"), this is where the system contains the related form files. You should version control it.

/InlineCSharpFunctions/: If you create inline C# functions, the system places the C# code you create in the respective files here. You should version control it. Please note that the meta information about templates you create in the GUI is stored in other places, too.

/LogFiles/: All the log files are stored in this folder. You do not have to version control it.

/PackageLicenses/: If you install commercial packages, this is where the system places their trial and commercial licenses. Normally, you do not need to version control it. License files can be placed here manually and should be backup-stored somewhere else for security reasons.

/Packages/: When you install packages, they place the original packages here plus some meta data about their installation status. The files are unchanged here after the installation. Normally, you will not need to version control this folder.

/TreeDefinitions/: All the customizations of the Administrative console GUI are kept here as XML-based tree definition files. You need to version control it.

/app_offline.htm: This file is used automatically when the website has to go offline (e.g. when you install some package). It gets copied to the website’s root folder and then removed from the root when the site goes online again. You do not need to version control it.

/Composite.config: C1 CMS controls all its application-related configuration data in this file. You must version control it.

SQL-Based Websites

An SQL-based CMS Website uses a database on a Microsoft SQL Server for its data store. So instead of version-controlling the files in /App_Data/Composite/DataStores, you must version control respective tables in this database by using a third-party SQL version control tools.

One of the tools recommended in the CMS Community is Redgate SQL Source Control.

C1 CMS Tools

To some extent, you can use the tools available as C1 CMS extension modules (packages) for version-controlling tasks.

C1 CMS Content Versioning (Composite.Versioning.ContentVersioning) allows you to track changes to pages, media files and data in data types as well as keep an audit trail within the CMS Administrative Console. As the name suggests it only handles content, so if you need to track changes to the content on your CMS Website, you might consider using it.

Please read more in "Composite.Versioning.ContentVersioning".

CMS Package Creator (Composite.Tools.PackageCreator) allows you to export content and functionality to a single-file package, which you can later install (import) on this or other CMS Websites.

If you are mostly working in the C1 CMS Adminsitrative GUI (for example, creating XSLT functions, data types, templates etc) you should consider using this tool.

Please read more in "Composite.Tools. PackageCreator".