Effective collaboration is key to the success of any enterprise-level project, so it’s essential to understand how to work well with others in shared projects. To give others access to a project that you’ve created, you can add them as a collaborator. When you add a user (or group of users) as collaborators on a project, it means that they have permission to edit the project files and commit changes to the master copy on the server while you may be actively working on a local copy. The only project setting they’ll be able to change is the default editor—all other project settings will be disabled for editing.
Anaconda Enterprise creates a repository for each project that you create, and will authorize only those users who have been explicitly added as project collaborators to update the version control repository configured for your organization with their changes to the project.
Anaconda Enterprise tracks all changes to a project and lets you know when files have been updated, so you can choose which version to use.

​
Sharing a project

You can share a project with specific users or groups of users
  1. Click Projects to view all of your projects.
  2. Click the project you want to share and select Share in the left menu.
  3. Start typing the name of the user or group in the Add New Collaborator drop-down to search for matches. Select the one that corresponds to what you want and click Add.
To unshare—or remove access to—a project, check the large X next to the collaborator you want to remove and click Remove to confirm your selection.
If you remove a collaborator from a project while they have a session open for that project, they might see a 500 Internal Server Error message. To avoid this, ask them to close their running session before you remove them from the project.
Any collaborators you share your project with will see the project in their Projects list when they log in to AE, and if others share their projects with you, they’ll appear in yours.

​
Getting updates from other users

When a collaborator makes a change to the project, a badge will appear beside the Fetch Changes icon. Click this icon to pull changes from the server and update your local copy of the project with any changes made by other collaborators. Anaconda Enterprise compares the copy of the project files you have locally with those on the server and notifies if any files have a conflict. If there is no file conflict, your local copies are updated.
Fetching the latest changes may overwrite or delete your local copy of files without warning if a collaborator has committed changes to the server and you have not made changes to the same files, as there is no file conflict.
EXAMPLE:
  • Alice and Bob are both collaborators a project that includes file1.txt.
  • Alice deletes file1.txt from her local copy of the project and commits her changes to the server.
  • Bob pulls the latest changes from the server. Bob hasn’t edited file1.txt, so file1.txt is deleted from Bob’s local version of the project. Bob’s local copy of the project and the version on the server now match exactly.
If the updates on the server conflict with changes you have made locally, you can choose one of the following options:
  • Cancel the Pull.
  • Keep theirs and Pull—discards your local changes in favor of theirs. Your changes will be lost.
  • Keep mine and Pull—discards changes on the server in favor of your local changes. Their changes will be overwritten.
  • Keep both and Pull—saves the conflicting files with different filenames so you can compare the content of the files and decide how you want to reconcile the differences. See resolving file conflicts below for more information.
If you have a file open that has been modified by fetching changes, close and reopen the file for the changes to be reflected. Otherwise, the next time you save the file, you may see a “File has been overwritten on disk” alert in JupyterLab. This alert lets you choose whether to cancel the save, discard the current version and open the version of the file on disk, or overwrite the file on disk with the current version.

​
Committing your changes

After you have saved your changes locally, click the Commit Changes icon to update the master copy on the server with your changes. If your changes conflict with updates made by other collaborators, a list of the files impacted will be highlighted in red. You may choose how you want to proceed from the following options:
  • Cancel the Commit.
  • Proceed with the Commit—overwrites your collaborators’ changes. Proceed with caution when choosing this option. Collaborators may not appreciate having their work overwritten, and important work may be lost in the process.
  • Selectively Commit—commit only those files which don’t have conflicts by unchecking the ones highlighted in red.
Committing changes to the server involves a full sync, so any changes that have been made to the project on the server–that do not conflict with your changes–are pulled in the process. This means that after committing your changes, your local copy will match the master copy on the server.

​
Resolving file conflicts

File conflicts result whenever you have updated a file locally, while a collaborator has changed that same file in their copy of the project and committed their changes to the master copy on the server. In these cases, you may want to select Keep both and Pull to save the conflicting files with different filenames. This enables you to compare the content of the files and decide the best approach to take to reconcile the differences. The solution will likely involve manually editing the file to combine both sets of changes and then committing the file. EXAMPLE: If a file is named Some Data.txt and Alice has committed updates to that file on the server, your new local copy of the file from the server—containing Alice’s changes—will be named Some Data.txt (Alice's conflicted file). Your local copy named Some Data.txt will not change.