Keyboard shortcuts

Press or to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Using Ethersync for pair programming

One use case for Ethersync is to do a short collaboration session on an existing project. You could do this, for example, to pair program with another person, editing code together at the same time.

This would also work for more than two people. One person will start the session, and others can connect to it.

Step-by-step guide

1. Starting conditions

If both people already have a copy of the project, make sure you're on the same state – for example, by making sure that you're on the same commit with a clean working tree. If the joining peer has a different state, those changes will be overwritten.

An alternative is that the joining peer starts from scratch, with an empty directory.

Make sure you're both inside the project directory on the command line.

Also this guide assumes you're in the same local network. For other connections consider reading the section on connection making.

2. First peer

To start the session, run:

ethersync share

This will print, among other initialization information, a join code, which looks like 3-exhausted-bananas.

You can share this with one other person, to allow them to connect.

3. Other peers

To join a session, run a command like this:

ethersync join 3-exhausted-bananas

This should show you a message like "Connected to peer: ...". The hosting daemon should show a message like "Peer connected: ...".

4. Collaborate!

Connected peers can now open files and edit them together. Note the common pitfalls.

5. Stop Ethersync

To stop collaborating, stop the daemon (by pressing Ctrl-C in its terminal). Both peers will still have the code they worked on, and can continue their work independently.

6. Reconnect later

If you later want to do another pairing session, make sure that you understand Ethersync's offline support feature and the local first concept. When you re-start Ethersync, it will scan for changes you've made in the meantime, and try to send them to the other peer. It is probably safest if you delete the CRDT state in .ethersync/doc as a joining peer. The hosting peer doesn't need to do that, it will simply update their state to the latest file content and share that with others.