sync2dev

sync2dev is a simple command line tool allowing you to work together on the same development server, without accidentily overriding each others changes without a backup.

It supports file transfer using SSH/SCP or (S)FTP, and authentication using (optionally safed) passwords, or SSH certificates.

Features

• Easy: Just a single command
• Automatically upload files to your dev server
• Prevent others from accidentally overriding your changes
• Supports SSH/SCP/SFTP/FTP/FTPS
• Works everywhere: Every OS, Every IDE

Usage

There is only a single command to start the program:

$ sync2dev

On startup, sync2dev will try to find a .sync2dev file in the current or any parent directory. If it can't find any, it will ask you to create a new configuration in the current folder.

>>> WARNING! NEVER COMMIT THE .sync2dev FILE TO YOUR GIT <<<

This file is local to your machine, and may contain the connection string and also usernames and passwords to your development server in plaintext! sync2dev will never upload this file itself, but other tools might. Make sure you exclude the file everywhere, but at least add it to .gitignore.

How does it work?

sync2dev offers the same functionality as most other similar tools or IDE's: Whenever it detects a file change, it uploads the file to a configured server.

But in contrast to those tools, it makes sure that only one person can modify a single file at a time without also triggering a merge in git.

It accomplishes that by comparing the modification timestamps before uploading. If the version on the server is newer than your local version, sync2dev will not allow you to upload the file. It keeps track of the files you changed to make sure you can continue to edit the file even if the server time does not exactly match your local time.

However, you can still regain access to a file by committing your changes: As soon as you commit, you can claim the lock on any file, even if there are newer versions on the server. This is safe if your team members also use sync2dev. The file will be locked for them, so to claim the lock again for themselves, they also have to commit their changes. With both versions committed and safed to your Git repository, you can later resolve the merge conflict (if there is any).