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.
Sharing a project
You can share a project with specific users or groups of users- Click Projects to view all of your projects.
- Click the project you want to share and select Share in the left menu.
- 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.

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.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.
- 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
, sofile1.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.
- 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.
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 namedSome 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.