diff --git a/content/en/docs/refguide/version-control/_index.md b/content/en/docs/refguide/version-control/_index.md index 85a06788fb4..f6279d62a7f 100644 --- a/content/en/docs/refguide/version-control/_index.md +++ b/content/en/docs/refguide/version-control/_index.md @@ -18,135 +18,54 @@ Version Control allows you to manage your app development in two ways: Version control in Mendix is built on top [Git](https://git-scm.com). The concepts will be familiar to seasoned users of these version control systems (VCS). Mendix simplifies the VCS commands by building them into Studio Pro and the Mendix Portal. -## Concepts {#concepts} +### Mendix Team Server -### Team Server {#team-server} +[Mendix Team Server](/developerportal/repository/team-server/) is the Mendix-hosted environment that stores all Mendix apps. It facilitates versioning your apps by integrating them into a version control system. Mendix Studio Pro integrates with the Team Server allowing you to create and update apps, commit changes, and merge model versions with one click. -[Team Server](/developerportal/repository/team-server/) is where all the committed versions of Mendix apps are stored. If you commit a revision of an app, it is stored on the Team Server. +## Frequently Asked Questions -To commit to the Team Server you will need to have a role in the app which allows you to edit the app. For more information, see the [Team Roles](/developerportal/general/app-roles/#team-roles) section *App Roles*. +### What Version Control System Is Team Server Built On? {#which-team-server} -For more information on the Team Server and technologies involved, see [Version Control FAQ](/refguide/version-control-faq/). +Mendix Team Server is based on proven technology. Initially it was based only on top of Subversion (SVN), also called Team Server SVN. The Team Server only supports storing apps using Git technology, referred to as Team Server Git. -### Repository {#repository} +### How Much Storage Space Is Provided with Team Server? -Within the [Team Server](#team-server) each app is stored in a repository. This repository contains all the [committed revisions](#commit) for the [Branches](#branches) of the app. +Storage space is unlimited for apps connected to a commercial license. 1 GB of free storage is provided for your company account for apps not (yet) connected to a commercial license. -### Revision {#revision} +### What Happens with My Valuable and Confidential Data? -A revision is the version of your app at a moment in time, stored on the [Team Server](#team-server). +Mendix adheres to strict security standards and considers you the sole owner of your data. Only Mendix Cloud Infrastructure Engineers can access data and will only do so for troubleshooting. Your data is backed up for one year, and the backups are retained for one year after app deletion. You can get a backup of your data at any time by using default Git tools, or, if your app was deleted, by filing a [Mendix Support](https://support.mendix.com/) ticket. -Each revision of your app is given a unique alphanumeric identifier which enables you to find it in future. A new revision is created from Studio Pro when the app is committed to the repository. +### Retrieve and Commit + Push Actions Are Getting Slower -### Working Copy {#working-copy} +This may be caused by the way the storage format of Git interacts with the way the Mendix model stores changes, which can accumulate substantial disk space over time. Studio Pro periodically optimizes your repository if [automatic repository optimization](/refguide/preferences-dialog/#optimization) is enabled. -A working copy is the version of your app which is currently being worked on in Studio Pro. There is one working copy for each development line of the app. This model is held locally, on each computer where development work is taking place. +You can run `git gc` in the command line to manually optimize the repository. `git gc` runs a number of housekeeping tasks, but primarily pack files are created. Pack files store just the changes to the files, which reduces the amount of data which needs to be stored. -### Merge {#merge} +## Cloning my Project Takes a Long Time -Merging is the action of taking one [revision](#revision) of an app and applying the differences which have been made in a different revision. See the [Merging Branches](#merging-branches) section for more information. +Cloning or downloading your app consists of several steps. First the required data is downloaded from the server and then a local unpacking process is executed. The duration of the clone process depends on your repository size, internet connection and computer performance. In case cloning is taking a very long time, consider changing the [Clone type](/refguide/clone-type/) or [troubleshoot repository size](/refguide/troubleshoot-repository-size/). -If any of the differences cannot be applied, then there is a [conflict](#conflict). +## Can I Use the Subversion Version of the Team Server? -### Conflict {#conflict} +No, in Mendix 11, we are supporting only Git-versioned apps. You need to migrate your SVN app to Git to use Mendix 11. For more information on how to migrate, see [Migrate to Git](/developerportal/general/migrate-to-git/) in *Apps*. -A conflict occurs when two versions of the app cannot be combined automatically. This happens when the same document has been changed in a Studio Pro working copy and a committed [revision](#revision) and these changes cannot be reconciled. These are some examples: +## Can I Use Third-Party Tools to Connect to the Team Server? {#third-party-tools} -* The properties of a widget are changed in the revision and the working copy but to different settings -* A document is moved or deleted in the revision but has been changed in a different way in the working copy +Yes, as the Team Server is based on a full implementation of Git. You can directly use third-party tools like GitHub Desktop. For more information on how to set this up, see the [External Tools](/refguide/using-version-control-in-studio-pro/#external-tools) section in *Using Version Control in Studio Pro*. -When a conflict occurs, a developer has to intervene to decide how it should be resolved before it can be committed to the Team Server as a new revision. +## Is It Possible to Connect to a Third-Party or On-Premises Version Control Server? -### Pull {#pull} +Yes, it is possible to connect to a third-party Git version control repository, which is often called BYO-GIT (Bring Your Own Git). -Pulling is the action, invoked in Studio Pro, which gets the latest revision of the current [development line](#development-line) from the repository and merges the differences into the current working copy. +For more information about limitations and the supported Git repositories, see the [Introduction](/refguide/on-premises-git/#intro) and [Preparing Your Repository](/refguide/on-premises-git/#preparing-your-repo) sections in *Working with Git On-Premises Version Control Server*. -### Commit/Push {#commit} +## Does Mendix 11 Support Pull Requests and Peer Reviews? -Committing is the action, invoked in Studio Pro, of creating a set of changes and pushing all your changes to the [repository](#repository) and making a new [revision](#revision). It is possible to store the committed data in a local repository, but not yet push it to the central [repository](#repository). +Studio Pro supports peer review and merging through the version control functionalities available in Studio Pro. For more information on how to set this process up, see [Using Version Control in Studio Pro](/refguide/using-version-control-in-studio-pro/). +Currently, Mendix does not support pull or merge requests through the Team Server for Mendix. When using third-party tools it is possible to review the following code extensions: -If there are no conflicts, the changes are then sent to the repository to make a new revision. - -### Development Line {#development-line} - -Development of an app is done in a development line where a set of related changes is made. There are two types of development lines: the [main line](#main-line) and [branch lines](#branch-line). - -#### Main Line {#main-line} - -The main line is the initial development line for the app and is usually kept as the version which will be deployed to the production environment. Simple apps, and apps which do not require a high degree of collaboration, may only have a main line. - -#### Branch Line {#branch-line} - -A branch line is a way of making an independent set of changes which can be tested away from the main line. - -See the [Branches](#branches) section below for more information on how branch lines can be used. - -### Tag {#tag} - -A Tag is a way of identifying a commit in addition to the [revision](#revision) number. It is specified by the developer and has four parts: - -* Major: used to identify significant new functionality, a new user interface, or other important change -* Minor: used to identify new functionality which augments the main function of the app -* Patch: used to identify a fix to an error in a previously-released app -* Revision: this is added automatically and is the revision number of the commit - -### Repository Service - -The Repository Service manages communication between Studio Pro and other supporting services (for example, Team Server). The developer will not generally be aware that they are communicating via the Repository Service. - -### Mendix MPR Storage {#mpr-format} - -An app modeled in Mendix is stored in an *.mpr* file, a database that contains data on all documents, such as microflows, workflows, pages. Studio Pro or the [mx Command-Line Tool](/refguide/mx-command-line-tool/) is required to inspect changes in the *.mpr*. - -{{% alert color="warning" %}} -Manually modifying files belonging to the *.mpr* storage format such as the *.mpr* file or the *mprcontents* directory (for example, when resolving file conflicts through third-party tooling), will lead to a corrupted state. To recover from a corrupted state a previous commit will need to be restored. -{{% /alert %}} -{{% alert color="warning" %}} -Renaming the app by renaming the *.mpr* file is not supported. Renaming your app when using version control is only supported via the Mendix Portal. For more information, see the [Page Header](/developerportal/general-settings/#settings-page-header) section in *Settings*. -{{% /alert %}} - -## Branches {#branches} - -With more complex apps, you may want to manage your code in a more sophisticated way. For example, you may want to develop new features separately from the currently deployed version of your app so that you can fix any bugs without having to release all the new features. This is done using [Branch Lines](#branch-line). - -If you are already familiar with using branches, you can check the [Branching Best-Practices](/refguide/using-version-control-in-studio-pro/#branching-best-practices) section of *Using Version Control in Studio Pro* for advice on how to use branches when developing your Mendix app. - -### Main Line - -All apps are developed along the main line. Here you have all development happening along a single line, with all changes built upon the previous revision: - -{{< figure src="/attachments/refguide/version-control/image7.png" class="no-border" >}} - -### Branch Line - -When you add a branch line, you take a copy of an existing [revision](#revision) and work separately on that copy. Changes made to one branch do not impact any other branches. - -In Mendix each commit within a [repository](#repository) is given a unique identifier. - -{{< figure src="/attachments/refguide/version-control/image8.png" class="no-border" >}} - -### Merging Branches {#merging-branches} - -You may have a branch line which will continue independently and never need to be combined with any other development lines. For example, you may create a branch for a particular release of your app and only ever use it to fix bugs in that release. - -On the other hand, you may want to add the features from one branch line into another development line. These are two cases for doing this: - -* You develop new features in a branch line and want to include them in your main development line -* You want to take advantage of a bug fix which was made on another branch line - -You can merge a specific revision of a branch line into your current [working copy](#working-copy). If, for example, you were working on the main line updated to revision 6, you can [merge](#merge) revision 5 from another branch line into your working copy. Then you can commit the result to create revision 7. If you want to merge several different committed changes from a branch, you will need to select a range of revisions which includes all the changes. - -{{< figure src="/attachments/refguide/version-control/image9.png" class="no-border" >}} - -{{% alert color="info" %}} - -You are expected to merge branch lines into the main line before upgrading to a version that is one or more **major** versions newer than the current one. -It is also highly recommended to either commit or revert all changes before such an upgrade so there are no uncommitted changes during the upgrade. - -{{% /alert %}} - -There may be conflicts during the merge, and these will have to be resolved before you can commit the changes to your app. - -Note that errors can be introduced by the [merge](#merge) process even if no conflicts are identified during the merge. Errors are inconsistencies which are flagged in Studio Pro and will prevent the app from being deployed. They could lead to a revision not being deployable, so it is important to check for errors after you have done a merge. +* code for Java and JavaScript actions +* HTML/CSS for theming ## Documents in This Category diff --git a/content/en/docs/refguide/version-control/configure/_index.md b/content/en/docs/refguide/version-control/configure/_index.md new file mode 100644 index 00000000000..0a55e701e8d --- /dev/null +++ b/content/en/docs/refguide/version-control/configure/_index.md @@ -0,0 +1,15 @@ +--- +title: "Configuring Version Control" +url: /refguide/uversion-control/configure/ +linktitle: "Using Version Control" +weight: 30 +description: "Describes how to configure version control for your Mendix application." +--- + +## Introduction + +This document describes how to configure version control in Mendix Studio Pro. + +For more information on related concepts and the theory behind how version control works in Mendix, see [Version Control](/refguide/version-control/). + +[TBD] \ No newline at end of file diff --git a/content/en/docs/refguide/version-control/using-version-control-in-studio-pro/auto-fetch.md b/content/en/docs/refguide/version-control/configure/auto-fetch.md similarity index 100% rename from content/en/docs/refguide/version-control/using-version-control-in-studio-pro/auto-fetch.md rename to content/en/docs/refguide/version-control/configure/auto-fetch.md diff --git a/content/en/docs/refguide/version-control/using-version-control-in-studio-pro/clone-type.md b/content/en/docs/refguide/version-control/configure/clone-type.md similarity index 100% rename from content/en/docs/refguide/version-control/using-version-control-in-studio-pro/clone-type.md rename to content/en/docs/refguide/version-control/configure/clone-type.md diff --git a/content/en/docs/refguide/version-control/using-version-control-in-studio-pro/git-storage-optimization-dialog.md b/content/en/docs/refguide/version-control/configure/git-storage-optimization-dialog.md similarity index 100% rename from content/en/docs/refguide/version-control/using-version-control-in-studio-pro/git-storage-optimization-dialog.md rename to content/en/docs/refguide/version-control/configure/git-storage-optimization-dialog.md diff --git a/content/en/docs/refguide/version-control/on-premises-git.md b/content/en/docs/refguide/version-control/configure/on-premises-git.md similarity index 99% rename from content/en/docs/refguide/version-control/on-premises-git.md rename to content/en/docs/refguide/version-control/configure/on-premises-git.md index 9d76b15f906..cb99aacdae2 100644 --- a/content/en/docs/refguide/version-control/on-premises-git.md +++ b/content/en/docs/refguide/version-control/configure/on-premises-git.md @@ -1,8 +1,7 @@ --- -title: "Working with Git On-Premises Version Control Server" -linktitle: "Git On-Premises Version Control Server" +title: "Optional: Working with Private Git" url: /refguide/on-premises-git/ -weight: 60 +weight: 80 description: "Introduces how to work with Git on-premises version control server." aliases: - /howto/collaboration-requirements-management/on-premises-git-howto/ diff --git a/content/en/docs/refguide/version-control/using-version-control-in-studio-pro/_index.md b/content/en/docs/refguide/version-control/using-version-control-in-studio-pro/_index.md index 1a9a89901a7..681f9384573 100644 --- a/content/en/docs/refguide/version-control/using-version-control-in-studio-pro/_index.md +++ b/content/en/docs/refguide/version-control/using-version-control-in-studio-pro/_index.md @@ -2,7 +2,7 @@ title: "Using Version Control in Studio Pro" url: /refguide/using-version-control-in-studio-pro/ linktitle: "Using Version Control" -weight: 10 +weight: 50 description: "Describes how to work with version control and how to resolve some issues which may arise." # Renamed from version-control-scenarios --- @@ -13,33 +13,6 @@ This document describes how to use version control in Mendix Studio Pro. For more information on related concepts and the theory behind how version control works in Mendix, see [Version Control](/refguide/version-control/). -## Starting an App with Version Control - -To start a new app with version control, do the following: - -1. Open Studio Pro. -2. In the **Select App** dialog box, click **Create New App**. -3. Select the starting point – an app template. -4. In the **App Settings** dialog box, make sure that **Enable online services** is set to *Yes*. This option creates a remote (Team Server) repository and an app in [Apps](https://sprintr.home.mendix.com/) of the Mendix Portal. -5. Optionally, change the default **App directory** set by Studio Pro. -6. Click **Create app**. - -The app is created on the Team Server, and a working copy is created in the **App directory**. This is opened in Studio Pro so that you can start working immediately. - -{{< figure src="/attachments/refguide/version-control/using-version-control-in-studio-pro/app-settings.png" class="no-border" >}} - -## Joining an App - -If there is already a Team Server-enabled app, you can be invited to join it (see [Team](/developerportal/general/team/)). - -Once you are a team member, provided that you have been given a role with sufficient rights, you can work on the app by doing the following: - -1. Choose **Open App** in Studio Pro. -2. Choose your app from the list of the **Open App** dialog box. -3. Click **Open in Studio Pro**. - -The app will be downloaded from the Team Server and opened in Studio Pro. - ## Day-to-Day Development Let us say you have a working copy of an app on disk. You make changes to the app and save them. Saved changes are not immediately visible to others. The documents, folders, and modules that have been changed can be identified by looking at the **status**. diff --git a/content/en/docs/refguide/version-control/version-control-enable.md b/content/en/docs/refguide/version-control/version-control-enable.md new file mode 100644 index 00000000000..263e9bc5e42 --- /dev/null +++ b/content/en/docs/refguide/version-control/version-control-enable.md @@ -0,0 +1,41 @@ +--- +title: "Enabling Version Control for Your App" +url: /refguide/version-control/enable/ +weight: 10 +description: "Learn how you can start or join an app that uses version control." +--- + +## Introduction {#intro} + +Version control is automatically enabled for every new Mendix application that you create. [TBD] + +## Starting an App with Version Control + +To start a new app with version control, do the following: + +1. Open Studio Pro. +2. In the **Select App** dialog box, click **Create New App**. +3. Select the starting point – an app template. +4. In the **App Settings** dialog box, make sure that **Enable online services** is set to **Yes**. This option creates a remote (Team Server) repository and an app in [Apps](https://sprintr.home.mendix.com/) of the Mendix Portal. +5. Optionally, change the default **App directory** set by Studio Pro. +6. Click **Create app**. + +The app is created on the Team Server, and a working copy is created in the **App directory**. This is opened in Studio Pro so that you can start working immediately. + +{{< figure src="/attachments/refguide/version-control/using-version-control-in-studio-pro/app-settings.png" class="no-border" >}} + +## Joining an App + +If there is already a Team Server-enabled app, you can be invited to join it (see [Team](/developerportal/general/team/)). + +Once you are a team member, provided that you have been given a role with sufficient rights, you can work on the app by doing the following: + +1. Choose **Open App** in Studio Pro. +2. Choose your app from the list of the **Open App** dialog box. +3. Click **Open in Studio Pro**. + +The app will be downloaded from the Team Server and opened in Studio Pro. + +## Enabling Version Control for an Existing App + +[add info: https://docs.mendix.com/refguide/upload-to-version-control-dialog/] \ No newline at end of file diff --git a/content/en/docs/refguide/version-control/version-control-faq.md b/content/en/docs/refguide/version-control/version-control-faq.md deleted file mode 100644 index feabffb8ce6..00000000000 --- a/content/en/docs/refguide/version-control/version-control-faq.md +++ /dev/null @@ -1,54 +0,0 @@ ---- -title: "Version Control FAQ" -url: /refguide/version-control-faq/ -weight: 30 -description: "Presents and explains several frequently asked questions about version control." ---- - -## Introduction - -[Mendix Team Server](/developerportal/repository/team-server/) is the Mendix-hosted environment that stores all Mendix apps. It facilitates versioning your apps by integrating them into a version control system. Mendix Studio Pro integrates with the Team Server allowing you to create and update apps, commit changes, and merge model versions with one click. - -## What Version Control System Is Team Server Built On? {#which-team-server} - -Mendix Team Server is based on proven technology. Initially it was based only on top of Subversion (SVN), also called Team Server SVN. The Team Server only supports storing apps using Git technology, referred to as Team Server Git. - -## How Much Storage Space Is Provided with Team Server? - -Storage space is unlimited for apps connected to a commercial license. 1 GB of free storage is provided for your company account for apps not (yet) connected to a commercial license. - -## What Happens with My Valuable and Confidential Data? - -Mendix adheres to strict security standards and considers you the sole owner of your data. Only Mendix Cloud Infrastructure Engineers can access data and will only do so for troubleshooting. Your data is backed up for one year, and the backups are retained for one year after app deletion. You can get a backup of your data at any time by using default Git tools, or, if your app was deleted, by filing a [Mendix Support](https://support.mendix.com/) ticket. - -## Retrieve and Commit + Push Actions Are Getting Slower - -This may be caused by the way the storage format of Git interacts with the way the Mendix model stores changes, which can accumulate substantial disk space over time. Studio Pro periodically optimizes your repository if [automatic repository optimization](/refguide/preferences-dialog/#optimization) is enabled. - -You can run `git gc` in the command line to manually optimize the repository. `git gc` runs a number of housekeeping tasks, but primarily pack files are created. Pack files store just the changes to the files, which reduces the amount of data which needs to be stored. - -## Cloning my Project Takes a Long Time - -Cloning or downloading your app consists of several steps. First the required data is downloaded from the server and then a local unpacking process is executed. The duration of the clone process depends on your repository size, internet connection and computer performance. In case cloning is taking a very long time, consider changing the [Clone type](/refguide/clone-type/) or [troubleshoot repository size](/refguide/troubleshoot-repository-size/). - -## Can I Use the Subversion Version of the Team Server? - -No, in Mendix 11, we are supporting only Git-versioned apps. You need to migrate your SVN app to Git to use Mendix 11. For more information on how to migrate, see [Migrate to Git](/developerportal/general/migrate-to-git/) in *Apps*. - -## Can I Use Third-Party Tools to Connect to the Team Server? {#third-party-tools} - -Yes, as the Team Server is based on a full implementation of Git. You can directly use third-party tools like GitHub Desktop. For more information on how to set this up, see the [External Tools](/refguide/using-version-control-in-studio-pro/#external-tools) section in *Using Version Control in Studio Pro*. - -## Is It Possible to Connect to a Third-Party or On-Premises Version Control Server? - -Yes, it is possible to connect to a third-party Git version control repository, which is often called BYO-GIT (Bring Your Own Git). - -For more information about limitations and the supported Git repositories, see the [Introduction](/refguide/on-premises-git/#intro) and [Preparing Your Repository](/refguide/on-premises-git/#preparing-your-repo) sections in *Working with Git On-Premises Version Control Server*. - -## Does Mendix 11 Support Pull Requests and Peer Reviews? - -Studio Pro supports peer review and merging through the version control functionalities available in Studio Pro. For more information on how to set this process up, see [Using Version Control in Studio Pro](/refguide/using-version-control-in-studio-pro/). -Currently, Mendix does not support pull or merge requests through the Team Server for Mendix. When using third-party tools it is possible to review the following code extensions: - -* code for Java and JavaScript actions -* HTML/CSS for theming diff --git a/content/en/docs/refguide/version-control/version-control-glossary.md b/content/en/docs/refguide/version-control/version-control-glossary.md new file mode 100644 index 00000000000..4af9f34a372 --- /dev/null +++ b/content/en/docs/refguide/version-control/version-control-glossary.md @@ -0,0 +1,139 @@ +--- +title: "Version Control Glossary" +url: /refguide/version-control/glossary/ +weight: 100 +description: "Presents and explains several concepts related to version control." +--- + +## Introduction + +## Concepts {#concepts} + +### Team Server {#team-server} + +[Team Server](/developerportal/repository/team-server/) is where all the committed versions of Mendix apps are stored. If you commit a revision of an app, it is stored on the Team Server. + +To commit to the Team Server you will need to have a role in the app which allows you to edit the app. For more information, see the [Team Roles](/developerportal/general/app-roles/#team-roles) section *App Roles*. + +For more information on the Team Server and technologies involved, see [Version Control FAQ](/refguide/version-control-faq/). + +### Repository {#repository} + +Within the [Team Server](#team-server) each app is stored in a repository. This repository contains all the [committed revisions](#commit) for the [Branches](#branches) of the app. + +### Revision {#revision} + +A revision is the version of your app at a moment in time, stored on the [Team Server](#team-server). + +Each revision of your app is given a unique alphanumeric identifier which enables you to find it in future. A new revision is created from Studio Pro when the app is committed to the repository. + +### Working Copy {#working-copy} + +A working copy is the version of your app which is currently being worked on in Studio Pro. There is one working copy for each development line of the app. This model is held locally, on each computer where development work is taking place. + +### Merge {#merge} + +Merging is the action of taking one [revision](#revision) of an app and applying the differences which have been made in a different revision. See the [Merging Branches](#merging-branches) section for more information. + +If any of the differences cannot be applied, then there is a [conflict](#conflict). + +### Conflict {#conflict} + +A conflict occurs when two versions of the app cannot be combined automatically. This happens when the same document has been changed in a Studio Pro working copy and a committed [revision](#revision) and these changes cannot be reconciled. These are some examples: + +* The properties of a widget are changed in the revision and the working copy but to different settings +* A document is moved or deleted in the revision but has been changed in a different way in the working copy + +When a conflict occurs, a developer has to intervene to decide how it should be resolved before it can be committed to the Team Server as a new revision. + +### Pull {#pull} + +Pulling is the action, invoked in Studio Pro, which gets the latest revision of the current [development line](#development-line) from the repository and merges the differences into the current working copy. + +### Commit/Push {#commit} + +Committing is the action, invoked in Studio Pro, of creating a set of changes and pushing all your changes to the [repository](#repository) and making a new [revision](#revision). It is possible to store the committed data in a local repository, but not yet push it to the central [repository](#repository). + +If there are no conflicts, the changes are then sent to the repository to make a new revision. + +### Development Line {#development-line} + +Development of an app is done in a development line where a set of related changes is made. There are two types of development lines: the [main line](#main-line) and [branch lines](#branch-line). + +#### Main Line {#main-line} + +The main line is the initial development line for the app and is usually kept as the version which will be deployed to the production environment. Simple apps, and apps which do not require a high degree of collaboration, may only have a main line. + +#### Branch Line {#branch-line} + +A branch line is a way of making an independent set of changes which can be tested away from the main line. + +See the [Branches](#branches) section below for more information on how branch lines can be used. + +### Tag {#tag} + +A Tag is a way of identifying a commit in addition to the [revision](#revision) number. It is specified by the developer and has four parts: + +* Major: used to identify significant new functionality, a new user interface, or other important change +* Minor: used to identify new functionality which augments the main function of the app +* Patch: used to identify a fix to an error in a previously-released app +* Revision: this is added automatically and is the revision number of the commit + +### Repository Service + +The Repository Service manages communication between Studio Pro and other supporting services (for example, Team Server). The developer will not generally be aware that they are communicating via the Repository Service. + +### Mendix MPR Storage {#mpr-format} + +An app modeled in Mendix is stored in an *.mpr* file, a database that contains data on all documents, such as microflows, workflows, pages. Studio Pro or the [mx Command-Line Tool](/refguide/mx-command-line-tool/) is required to inspect changes in the *.mpr*. + +{{% alert color="warning" %}} +Manually modifying files belonging to the *.mpr* storage format such as the *.mpr* file or the *mprcontents* directory (for example, when resolving file conflicts through third-party tooling), will lead to a corrupted state. To recover from a corrupted state a previous commit will need to be restored. +{{% /alert %}} +{{% alert color="warning" %}} +Renaming the app by renaming the *.mpr* file is not supported. Renaming your app when using version control is only supported via the Mendix Portal. For more information, see the [Page Header](/developerportal/general-settings/#settings-page-header) section in *Settings*. +{{% /alert %}} + +## Branches {#branches} + +With more complex apps, you may want to manage your code in a more sophisticated way. For example, you may want to develop new features separately from the currently deployed version of your app so that you can fix any bugs without having to release all the new features. This is done using [Branch Lines](#branch-line). + +If you are already familiar with using branches, you can check the [Branching Best-Practices](/refguide/using-version-control-in-studio-pro/#branching-best-practices) section of *Using Version Control in Studio Pro* for advice on how to use branches when developing your Mendix app. + +### Main Line + +All apps are developed along the main line. Here you have all development happening along a single line, with all changes built upon the previous revision: + +{{< figure src="/attachments/refguide/version-control/image7.png" class="no-border" >}} + +### Branch Line + +When you add a branch line, you take a copy of an existing [revision](#revision) and work separately on that copy. Changes made to one branch do not impact any other branches. + +In Mendix each commit within a [repository](#repository) is given a unique identifier. + +{{< figure src="/attachments/refguide/version-control/image8.png" class="no-border" >}} + +### Merging Branches {#merging-branches} + +You may have a branch line which will continue independently and never need to be combined with any other development lines. For example, you may create a branch for a particular release of your app and only ever use it to fix bugs in that release. + +On the other hand, you may want to add the features from one branch line into another development line. These are two cases for doing this: + +* You develop new features in a branch line and want to include them in your main development line +* You want to take advantage of a bug fix which was made on another branch line + +You can merge a specific revision of a branch line into your current [working copy](#working-copy). If, for example, you were working on the main line updated to revision 6, you can [merge](#merge) revision 5 from another branch line into your working copy. Then you can commit the result to create revision 7. If you want to merge several different committed changes from a branch, you will need to select a range of revisions which includes all the changes. + +{{< figure src="/attachments/refguide/version-control/image9.png" class="no-border" >}} + +{{% alert color="info" %}} + +You are expected to merge branch lines into the main line before upgrading to a version that is one or more **major** versions newer than the current one. +It is also highly recommended to either commit or revert all changes before such an upgrade so there are no uncommitted changes during the upgrade. + +{{% /alert %}} + +There may be conflicts during the merge, and these will have to be resolved before you can commit the changes to your app. + +Note that errors can be introduced by the [merge](#merge) process even if no conflicts are identified during the merge. Errors are inconsistencies which are flagged in Studio Pro and will prevent the app from being deployed. They could lead to a revision not being deployable, so it is important to check for errors after you have done a merge. diff --git a/content/en/docs/refguide/version-control/version-control-troubleshooting/_index.md b/content/en/docs/refguide/version-control/version-control-troubleshooting/_index.md index 8e63017f481..a3a5aac348d 100644 --- a/content/en/docs/refguide/version-control/version-control-troubleshooting/_index.md +++ b/content/en/docs/refguide/version-control/version-control-troubleshooting/_index.md @@ -2,7 +2,7 @@ title: "Troubleshooting Version Control" url: /refguide/troubleshoot-version-control-issues/ linktitle: "Troubleshoot Version Control" -weight: 20 +weight: 90 description: "Presents a list of problems and fixes for version control issues." aliases: - /howto/collaboration-requirements-management/troubleshoot-version-control-issues/