Bitrix Framework

It is not complicated to organize project support by using the version control system if you decide to control only files. To do so, you can use, for example, Mercurial a cross-platform distributed system of version control developed for efficient work with very big code repositories. The use of an add-in with a graphic interface is recommended.

Simple Diagram of Repositories

The diagram contains three elements:

• Central repository is the place where changes are stored.
• Copy for development - workplaces for developers, there may be several workplaces.
• Production website - ultimate target of all changes.

During work changes from Copy for development are transferred to the Central repository, and from it to the Production website.

How Work Is Organized

Developers have changed certain files. A person responsible for commits uses the command Hg Commit. A dialog appears which reflects the changes proper and where they were made:

The text in red means deletion, in green – addition. After the changes have been checked, click Commit and the changes are displayed in the Mercurial environment:

Then, we push the changes to the Central repository and go to the "Production" website. Changes in the "production" website are made from the command line. Also, we have to make sure whether the changes were made on the "production" website itself and, if necessary, transfer them to the Central repository and to Copies for development.

Difficulties

Kernel version on the website server and on the server Copy for developers may differ. That is why the kernel is exempted from the version control system. Technically, it is made by applying a set of rules for the setup file .hgignore.

There is one more difficulty. Kernel files are not changed by project developers but come from the "outside" as updates. In this case, the folder /bitrix/ cannot be just exempted, because it may contain, among other things, project files: modules, components, website templates, etc. As a result, the file .hgignore becomes excessive:

/bitrix/activities/bitrix/
/bitrix/admin
/bitrix/cache
/bitrix/components/bitrix/
/bitrix/gadgets/bitrix
/bitrix/image_uploader
/bitrix/images
/bitrix/js
/bitrix/managed_cache
/bitrix/stack_cache
/bitrix/modules/advertising
/bitrix/modules/bitrix.sitecommunity
...
/bitrix/modules/xdimport
/bitrix/modules/xmpp
/bitrix/modules/.htaccess
/bitrix/otp
/bitrix/sounds
/bitrix/template/
/bitrix/themes
/bitrix/tmp
/bitrix/tools
/bitrix/wizards/bitrix
/bitrix/[^/]*\.php$
/upload
/bitrix/php_interface
/bitrix/panel/
/bitrix/updates/
/bitrix/fonts/

Moreover, this file requires ongoing adjustments because new modules are issued or new folders are created in the system. They have to be added to the exemptions.

Support of the /local Folder

For the convenience of project developers, main project files are transferred from the folder /bitrix to the folder /local as a part of work on the new kernel D7 starting from kernel version 14.0.1. It will permit to separate changing project files from the product folder. Actually, it will suffice to add one folder /bitrix to the exemptions.

• activities - actions of the production project;
• components - components;
• gadgets - desktop gadgets;
• modules - modules;
• php_interface - init.php, folder user_lang;
• templates - templates of websites, templates of components, and templates of pages.

When processing folders, the /local folder will always have a priority over /bitrix. It means that if /local/templates/ and /bitrix/templates/ contain website templates with the same name, the template from /local will be connected.