65aaa607ab
Change made by: - running "gvt fetch" on each of the packages mentioned in Godeps/Godeps.json - `rm -rf Godeps` - tweaking the build scripts to not mention Godeps - tweaking the build scripts to test `./lib/...`, `./cmd/...` explicitly (to avoid testing vendor) - tweaking the build scripts to not juggle GOPATH for Godeps and instead set GO15VENDOREXPERIMENT. This also results in some updated packages at the same time I bet. Building with Go 1.3 and 1.4 still *works* but won't use our vendored dependencies - the user needs to have the actual packages in their GOPATH then, which they'll get with a normal "go get". Building with Go 1.6+ will get our vendored dependencies by default even when not using our build script, which is nice. By doing this we gain some freedom in that we can pick and choose manually what to include in vendor, as it's not based on just dependency analysis of our own code. This is also a risk as we might pick up dependencies we are unaware of, as the build may work locally with those packages present in GOPATH. On the other hand the build server will detect this as it has no packages in it's GOPATH beyond what is included in the repo. Recommended tool to manage dependencies is github.com/FiloSottile/gvt. |
||
|---|---|---|
| assets | ||
| cmd | ||
| debian | ||
| etc | ||
| gui | ||
| lib | ||
| man | ||
| script | ||
| test | ||
| vendor | ||
| .gitattributes | ||
| .gitignore | ||
| .mailmap | ||
| appveyor.yaml | ||
| AUTHORS | ||
| build.go | ||
| build.sh | ||
| CONDUCT.md | ||
| CONTRIBUTING.md | ||
| ISSUE_TEMPLATE.md | ||
| LICENSE | ||
| NICKS | ||
| README.md | ||
Syncthing
This is the Syncthing project which pursues the following goals:
-
Define a protocol for synchronization of a folder between a number of collaborating devices. This protocol should be well defined, unambiguous, easily understood, free to use, efficient, secure and language neutral. This is called the Block Exchange Protocol.
-
Provide the reference implementation to demonstrate the usability of said protocol. This is the
syncthingutility. We hope that alternative, compatible implementations of the protocol will arise.
The two are evolving together; the protocol is not to be considered stable until Syncthing 1.0 is released, at which point it is locked down for incompatible changes.
Getting Started
Take a look at the getting started guide.
There are a few examples for keeping Syncthing running in the background on your system in the etc directory. There are also several GUI implementations for Windows, Mac and Linux.
Getting in Touch
The first and best point of contact is the Forum. There is also an IRC
channel, #syncthing on Freenode (with a web client), for talking
directly to developers and users. If you've found something that is clearly a
bug, feel free to report it in the GitHub issue tracker.
Building
Building Syncthing from source is easy, and there's a guide that describes it for both Unix and Windows systems.
Signed Releases
As of v0.10.15 and onwards release binaries are GPG signed with the key D26E6ED000654A3E, available from https://syncthing.net/security.html and most key servers.
There is also a built in automatic upgrade mechanism (disabled in some distribution channels) which uses a compiled in ECDSA signature. Mac OS X binaries are also properly code signed.
Documentation
Please see the Syncthing documentation site.
All code is licensed under the MPLv2 License.