About the Perforce Helix version control system
Greetings
A search through the archives of Habr showed that almost nothing was written about Perforce Helix, and only an overview article about the extension for VS and the translation of an old English-language article Dear Perforce: fcuk you is available in Runet. At the same time, Perforce was often mentioned in the comments to the article on the version control systems used, so I wanted to publish a couple of review articles on the functionality of Perforce Helix, which perhaps would help someone to understand this platform, that is, exclusively for the information component.
Disclaimer : I am not a professional developer, so I did not use Helix in a real product. For writing the article, I used the documentation , a free version for 20 users , and also suggested that parts of my students use Helix when developing a small open-source project. The purpose of this and subsequent articles is to be a source of information about the platform, so I look forward to your participation in the comments.
Perforce, Helix, p4, p4d - you can find several names of what we do Perforce Software (hereinafter - Perforce) for more than 20 years. In this paragraph, I want to fix the status quo by the name of the components of the Perforce project management platform (for today):
')
p4d (Helix Versioning Engine) - engine from Perforce for version control,
p4 - CLI to work with p4d,
p4v is a GUI client for working with p4d,
Helix - a single platform from Perforce, which includes:
1 - components for version control (p4d, p4, p4v, plug-ins to work from IDE),
2 - Helix Swarm component for code review,
3 - component Helix Insights for analytics of work performed, the state of the project, the performance of teams, fixes bugs.
4 - GitSwarm component based on GitLab and allowing you to work in the usual git workflow in conjunction with Swarm and use the advantages of p4d.
Helix has a client-server architecture and consists of:
- Servers with the p4d engine that provides users with repositories (in Helix terminology, this is depot) and supports the database with information on working with files, engine configuration, user activity logs, etc.
- p4, p4v, plugins for working from IDE.
Below, I mention the Helix workflow defining concepts: changelist, shelving, streams, jobs, labels.
Any submission to the repository is uniquely determined by the numbered changelist value. A changelist must include changes in at least one file, and may include changes in thousands of files. Transactional is ensured here, so if during the transfer of 10 files the connection between p4d and the client is interrupted, none of the changes will go to the repository. The current version of each file is also numbered and incremented after each change.
If you want to submit changes to a review before submitting, you can use the shelving function, which allows you to send copies of modified files to a temporary shared repository (the “shelf” from shelve).
Streams are branches in Helix, the difference is that the stream model includes information about the possibilities and sequences of actions when working with them.
When you create a stream, you define its type, associated files, and the parent stream. When you switch between streams, the cut of your workspace automatically changes.
Let's take a look at the usual branching model, but let's display on it the logic of working with branches:
Let's say a branch was created to develop features (Project Y). After it has been successfully developed and tested, I want to embed the feature into the project. But during the development of the features, the Mainline (master branch) has changed, so before merging, it is necessary to make sure that Project Y responds to the current changes in the Mainline, and only then migrate Y from the Mainline.
p4v includes a handy tool to display this information:
More stable streams are above Mainline, unstable - below.
In Helix terminology, there are 2 types of branch operations:
1 - merge down,
2 - copy up.
The basic principle of working with streams is: before adding changes made in a less stable stream B to a more stable A (copy up B, A), all changes in a more stable stream A must be added to a less stable B (merge down A, B).
The next icon means that before you copy the changes to the parent stream, you need to update it from the parent.
Using streams automates branching, but you can use familiar to all branches.
In addition to using changelists and streams, Helix includes additional methods for organizing work:
1 - Jobs are attached to the changelist and display the status of work on the bug. They are easily integrated with third-party bug trackers and are configured by the administrator: not only the creator and the dependent bug can be displayed in them, but also any other fields can be added.
2 - Labels are attached to file revisions and allow you to group them. If the changelist defines a list of files in one revision, then labes can belong to a group of files from different revisions. They can be useful when you want to merge files in relation to a release or a successful build, mark critical project components, etc.
Helix is a heavyweight proprietary SCR, designed specifically for large-scale projects and distributed teams, and therefore has a number of features and functionality required for this.
To meet the perpetual precepts (scalability, fault tolerance, performance) Helix supports various server configurations:
- Proxy servers are used when connection bandwidth is limited. By tracking frequent calls to individual files, the proxy reduces the number of calls directly to the server and balances the network traffic.
- Server brokers use policies for clients that allow load balancing of incoming calls.
- Server replicas mirror the hottest (or all) primary server data.
The type of server is determined by its configuration and can be configured by the administrator. Due to the flexibility of configuring servers, you can achieve maximum engine performance by honing it specifically for the needs of teams. An example would be the commit-edge architecture:
- Commit-server store project data and metadata
- Edge servers are a replica of a commit server and a copy of the workspaces of those users accessing them. Such servers process only readonly operations and rewriting operations of only those files that are located in users' workspaces.
This architecture eases the load on the central commit-server, which increases performance.
One of the components of Helix is the Insights tool for presenting important information about the status of a project, code, and command performance. Insights displays a graphical representation of such information. Metrics are completely different, moreover they are customized using the API.
Helix supports both paradigms.
In the case of a centralized approach, users work directly with the p4d server. The repository slice in their workspaces determines the files that users can work with.
Everything is familiar and does not need additional comments. Traditional principles are also followed with a distributed approach.
An interesting feature of Helix is a hybrid approach that allows different users to either connect directly to the server, or use their own local servers, by connecting to the central repository via push.
For developers who are used to Git, but want to enjoy the benefits and features of p4d (described above), there is a GitSwarm component that includes the GitFusion service, which uses p4d as a backend, and a web interface for team interaction and project management:
In my opinion, this is really cool, as the transition to another SLE is always a painful process, and Helix allows you to stay on your favorite git'e, while carrying out all the operations through your engine.
So, in this part a general overview of the components of the Helix system was made, concepts defining workflow p4d are given, and also some of the system features are described.
What I wanted to express in this part: Perforce carries a very powerful p4d engine capable of scalability and fault tolerance, which can be easily integrated with git workflow, but also ready for work via the p4 command line or IDE plugins . Therefore, if something is impossible (or difficult) to do through Git, then you can easily switch to p4d, and vice versa.
Since the platform itself is very functional, in the future I want to look at each of the components individually and describe in more detail the principles of their work.
I wish those readers who had experience with Helix shared their impressions.
A search through the archives of Habr showed that almost nothing was written about Perforce Helix, and only an overview article about the extension for VS and the translation of an old English-language article Dear Perforce: fcuk you is available in Runet. At the same time, Perforce was often mentioned in the comments to the article on the version control systems used, so I wanted to publish a couple of review articles on the functionality of Perforce Helix, which perhaps would help someone to understand this platform, that is, exclusively for the information component.
Disclaimer : I am not a professional developer, so I did not use Helix in a real product. For writing the article, I used the documentation , a free version for 20 users , and also suggested that parts of my students use Helix when developing a small open-source project. The purpose of this and subsequent articles is to be a source of information about the platform, so I look forward to your participation in the comments.
Understand the terminology
Perforce, Helix, p4, p4d - you can find several names of what we do Perforce Software (hereinafter - Perforce) for more than 20 years. In this paragraph, I want to fix the status quo by the name of the components of the Perforce project management platform (for today):
')
p4d (Helix Versioning Engine) - engine from Perforce for version control,
p4 - CLI to work with p4d,
p4v is a GUI client for working with p4d,
Helix - a single platform from Perforce, which includes:
1 - components for version control (p4d, p4, p4v, plug-ins to work from IDE),
2 - Helix Swarm component for code review,
3 - component Helix Insights for analytics of work performed, the state of the project, the performance of teams, fixes bugs.
4 - GitSwarm component based on GitLab and allowing you to work in the usual git workflow in conjunction with Swarm and use the advantages of p4d.
Helix has a client-server architecture and consists of:
- Servers with the p4d engine that provides users with repositories (in Helix terminology, this is depot) and supports the database with information on working with files, engine configuration, user activity logs, etc.
- p4, p4v, plugins for working from IDE.
Below, I mention the Helix workflow defining concepts: changelist, shelving, streams, jobs, labels.
Changelist shelving
Any submission to the repository is uniquely determined by the numbered changelist value. A changelist must include changes in at least one file, and may include changes in thousands of files. Transactional is ensured here, so if during the transfer of 10 files the connection between p4d and the client is interrupted, none of the changes will go to the repository. The current version of each file is also numbered and incremented after each change.
If you want to submit changes to a review before submitting, you can use the shelving function, which allows you to send copies of modified files to a temporary shared repository (the “shelf” from shelve).
Streams
Streams are branches in Helix, the difference is that the stream model includes information about the possibilities and sequences of actions when working with them.
When you create a stream, you define its type, associated files, and the parent stream. When you switch between streams, the cut of your workspace automatically changes.
Let's take a look at the usual branching model, but let's display on it the logic of working with branches:
Let's say a branch was created to develop features (Project Y). After it has been successfully developed and tested, I want to embed the feature into the project. But during the development of the features, the Mainline (master branch) has changed, so before merging, it is necessary to make sure that Project Y responds to the current changes in the Mainline, and only then migrate Y from the Mainline.
p4v includes a handy tool to display this information:
More stable streams are above Mainline, unstable - below.
In Helix terminology, there are 2 types of branch operations:
1 - merge down,
2 - copy up.
The basic principle of working with streams is: before adding changes made in a less stable stream B to a more stable A (copy up B, A), all changes in a more stable stream A must be added to a less stable B (merge down A, B).
The next icon means that before you copy the changes to the parent stream, you need to update it from the parent.
Using streams automates branching, but you can use familiar to all branches.
Jobs, Labels
In addition to using changelists and streams, Helix includes additional methods for organizing work:
1 - Jobs are attached to the changelist and display the status of work on the bug. They are easily integrated with third-party bug trackers and are configured by the administrator: not only the creator and the dependent bug can be displayed in them, but also any other fields can be added.
2 - Labels are attached to file revisions and allow you to group them. If the changelist defines a list of files in one revision, then labes can belong to a group of files from different revisions. They can be useful when you want to merge files in relation to a release or a successful build, mark critical project components, etc.
Components and some of the features of Helix
Helix is a heavyweight proprietary SCR, designed specifically for large-scale projects and distributed teams, and therefore has a number of features and functionality required for this.
Flexible Helix server configuration mechanisms
To meet the perpetual precepts (scalability, fault tolerance, performance) Helix supports various server configurations:
- Proxy servers are used when connection bandwidth is limited. By tracking frequent calls to individual files, the proxy reduces the number of calls directly to the server and balances the network traffic.
- Server brokers use policies for clients that allow load balancing of incoming calls.
- Server replicas mirror the hottest (or all) primary server data.
The type of server is determined by its configuration and can be configured by the administrator. Due to the flexibility of configuring servers, you can achieve maximum engine performance by honing it specifically for the needs of teams. An example would be the commit-edge architecture:
- Commit-server store project data and metadata
- Edge servers are a replica of a commit server and a copy of the workspaces of those users accessing them. Such servers process only readonly operations and rewriting operations of only those files that are located in users' workspaces.
This architecture eases the load on the central commit-server, which increases performance.
Analytics Insights
One of the components of Helix is the Insights tool for presenting important information about the status of a project, code, and command performance. Insights displays a graphical representation of such information. Metrics are completely different, moreover they are customized using the API.
Support for a centralized and distributed approach, GitSwarm
Helix supports both paradigms.
In the case of a centralized approach, users work directly with the p4d server. The repository slice in their workspaces determines the files that users can work with.
Everything is familiar and does not need additional comments. Traditional principles are also followed with a distributed approach.
An interesting feature of Helix is a hybrid approach that allows different users to either connect directly to the server, or use their own local servers, by connecting to the central repository via push.
For developers who are used to Git, but want to enjoy the benefits and features of p4d (described above), there is a GitSwarm component that includes the GitFusion service, which uses p4d as a backend, and a web interface for team interaction and project management:
In my opinion, this is really cool, as the transition to another SLE is always a painful process, and Helix allows you to stay on your favorite git'e, while carrying out all the operations through your engine.
Summarizing this part
So, in this part a general overview of the components of the Helix system was made, concepts defining workflow p4d are given, and also some of the system features are described.
What I wanted to express in this part: Perforce carries a very powerful p4d engine capable of scalability and fault tolerance, which can be easily integrated with git workflow, but also ready for work via the p4 command line or IDE plugins . Therefore, if something is impossible (or difficult) to do through Git, then you can easily switch to p4d, and vice versa.
Since the platform itself is very functional, in the future I want to look at each of the components individually and describe in more detail the principles of their work.
I wish those readers who had experience with Helix shared their impressions.
Source: https://habr.com/ru/post/280976/
All Articles