- Hardware and Software Requirements
- Server Installation
- Updating the License
- Deploying the UiPath Process Mining Profiler
- Deploying a Connector (.mvp)
- Updating UiPath Process Mining
- Updating a Customized Version of an App or Discovery Accelerator
- Installing a Training Environment
- Set up Single Sign-on Through Azure Active Directory
- Set up Single Sign-on Through Integrated Windows Authentication
- Adding Superadmin AD Groups
- Adding End-user AD Groups
- Two-Factor Authentication
- Introduction to AppOne
- Analyzing Data in AppOne
- Overview of Menus and Dashboards in AppOne
- Introduction to Purchase-to-Pay Discovery Accelerator
- Analyzing Data With Purchase-to-Pay Discovery Accelerator
- Overview of Menus and Dashboards
- Menu Compliance
- Deploying the Basic Connector
- Introduction to Basic Connector
- Input Tables of the Basic Connector
- Adding Tags
- Adding Automation Estimates
- Adding Due Dates
- Adding Reference Models
- Setting up Actionable Insights
- Setting Collapsible Charts
- Using the Output Dataset in AppOne
- Output Tables of the Basic Connector
- Introduction to SAP Connector
- SAP Input
- Checking the Data in the SAP Connector
- Adding Process Specific Tags to the SAP Connector for AppOne
- Adding Process Specific Due Dates to the SAP Connector for AppOne
- Adding Automation Estimates to the SAP Connector for AppOne
- Adding Attributes to the SAP Connector for AppOne
- Adding Activities to the SAP Connector for AppOne
- Adding Entities to the SAP Connector for AppOne
- HTML Panels
- Migrating Legacy Charts to New Charts
- Join Tables
- Global Tables
- Introduction to Table Items
- Display Format
- Rebrand and Restyle Apps and Discovery Accelerators
- Use Sharding in Your Applications
- Create an Anonymized Dataset
- Set up Automated Data Refreshes
- Use an Access Matrix to Enable Role-Based Access to Data
- Introduction to SQL Connectors
- Setting up a SQL Connector
- CData Sync Extractions
- Running a SQL Connector
- Editing Transformations
- Releasing a SQL Connector
- Scheduling Data Extraction
- Structure of Transformations
- Using SQL Connectors for Released Apps
- Generating a Cache With Scripts
- Setting up a Local Test Environment
- Separate Development and Production Environments
While working on an app with a team, multiple developers will be working and committing on the same branch. When you have a workspace of a branch, and someone else commits changes to that branch, your workspace will become outdated as it will not contain those changes.
You can only commit if your workspace is at the latest revision of the branch. You will often need to update before committing. See the illustration below.
Updating Your Workspace
Follow these steps to update your workspace.
Go to the Superadmin Workspaces tab.
Select the workspace you want to update from the Workspace drop-down list.
Click on the Workspace menu icon and select Update....
Updating your workspace will have one of the following possible results.
Your workspace was already up to date.
No-one else has made changes to the branch you are working on.
Your workspace was successfully updated.
You can now also see the changes that other developers made in the meantime.
Update successful with Warning.
An update has been done but there are still unresolved conflicts due to changes other developers made in the branch. Information is provided on how many commits have been updated.
The update failed.
Conflict in non-application file.
- Local modifications in non-application files conflict with changes made by someone else.
Add/add or delete/modify on file.
- A file with local modifications was deleted by someone else.
- You deleted a file another developer modified.
- You created a new file with the same name as a new file created by another developer.
When updating while your workspace contains local modifications, it is possible that your changes conflict with changes committed by another developer. In this case, your app will contain conflicts that need to be resolved before you can commit.
If your app contains conflicts, this will be visible in the workspace. See illustration below.
Conflicts in text files
When a conflict occurs in a file other than the
.mvp file while updating athe workspace, the default
Git merge conflict markers placed in the text file (
>>>>>>>>>>>>). This enables you to resolve the conflicts after the update has finished.
After resolving all conflicts, it is possible to commit your changes. The following options are available to resolve conflicts.
Resolve as mine
Pick your local modifications over the changes someone else made.
Note: the version number will be set to 2, which will be a local modification you still have to commit.
Resolve as theirs
Pick the changes that another developer has made.
Note: the version number will be set on 1, and there will not be any local modifications.
Mark as resolved
Ignore the conflict. However, you must investigate the current state and possibly make changes first to make sure it is correct. You are responsible for ensuring the application is in the correct state.