Helix DVCS 2015.2 - What's New?
The Perforce Helix Versioning Engine 2015.2 is out, and included among the many new features are improvements to its DVCS capabilities. These changes are aimed mainly at the communication between personal and shared servers. Today I’ll give you a quick overview - we’ll dive deeper into some of these features in a future post.
If you read my post on initializing like a pro, you might remember that I stressed the importance of picking the correct user name for your personal server if you want to push your changes to a shared server. In 2015.2 you can define a RemoteUser in your remote spec that allows you to keep separate user names for personal and shared servers.
For added benefit, ‘p4 login’ has been enhanced to take a remote spec argument:
p4 login –r some-remote-server
This means it is now very easy to authenticate against the shared server with the correct user name, making pushing and fetching much easier.
While we're on the subject of user names, a change pushed into another server gains an additional field, ImportedBy, that identifies the user who performed the push—this can be different from the user who submitted the change.
Now that changes can originate from different sources such as personal servers, we need a way to verify the identity of this change across all servers. For this purpose, the engineers have added yet another field to change: Identity. The content of this field is controlled server-wide by a configurable, submit.identity, that can take three different values depending on your strategy:
- generated as uuid, like 96000410-4616-403B-A9B5-172622DE027C
- generated as SHA1 checksum
- generated as “serverid,change”, like “sven.dvcs,12345”
You can search for a change with a given identity by using the –I option on ‘p4 describe’:
p4 describe –I 96000410-4616-403B-A9B5-172622DE027C
Changes pushed to another server do not cause any submit-triggers to fire. To be able to control and customize pushed changes, the Helix Versioning Engine has gained a few extra triggers: push-submit, push-content and push-commit for pre-, during-, and after-push operations respectively. I’ll discuss the details of these triggers and some use cases in another post soon.
An additional topic for a future post is the use of the tangent depot for rewriting local history when fetching with the new –t option, which allows you to rebase your local changes.
For now, why not check out the release notes and documentation on all the existing and new DVCS features?