mirror of https://github.com/perkeep/perkeep.git
102 lines
3.4 KiB
Plaintext
102 lines
3.4 KiB
Plaintext
Camlistore contributors regularly use Linux and OS X, and both are
|
|
100% supported.
|
|
|
|
Developing on Windows is sometimes broken, but should work. Let us
|
|
know if we broke something, or we accidentally depend on some
|
|
Unix-specific build tool somewhere.
|
|
|
|
See http://camlistore.org/docs/contributing for information on how to
|
|
contribute to the project and submit patches. Notably, we use Gerrit
|
|
for code review. Our Gerrit instance is at https://camlistore.org/r/
|
|
|
|
See architecture docs: https://camlistore.org/docs/
|
|
|
|
You can view docs for Camlistore packages with local godoc, or
|
|
godoc.org.
|
|
|
|
It's recommended you use git to fetch the source code, rather than
|
|
hack from a Camlistore release's zip file:
|
|
|
|
$ git clone https://camlistore.googlesource.com/camlistore
|
|
|
|
(We use github for distribution but its code review system is so poor,
|
|
we don't use its Pull Request mechanism. The Gerrit git server & code
|
|
review system is the main repo. See
|
|
http://camlistore.org/docs/contributing for how to use them. We might
|
|
support github for pull requests in the future, once it's properly
|
|
integrated with external code review tools. We had a meeting with Github
|
|
to discuss the ways in which their code review tools are poor.)
|
|
|
|
On Debian/Ubuntu, some deps to get started:
|
|
|
|
$ sudo apt-get install libsqlite3-dev sqlite3 pkg-config git
|
|
|
|
During development, rather than use the main binaries ("camput",
|
|
"camget", "camtool", "cammount", etc) directly, we instead use a
|
|
wrapper (devcam) that automatically configure the environment to use
|
|
the test server & test environment.
|
|
|
|
To build devcam:
|
|
|
|
$ go run make.go
|
|
|
|
And devcam will be in <camroot>/bin/devcam. You'll probably want to
|
|
symlink it into your $PATH.
|
|
|
|
Alternatively, if your Camlistore root is checked out at
|
|
$GOPATH/src/camlistore.org (optional, but natural for Go users), you
|
|
can just:
|
|
|
|
$ go install ./dev/devcam
|
|
|
|
The subcommands of devcam start the server or run camput/camget/etc:
|
|
|
|
$ devcam server # main server
|
|
$ devcam appengine # App Engine version of the server
|
|
$ devcam put # camput
|
|
$ devcam get # camget
|
|
$ devcam tool # camtool
|
|
$ devcam mount # cammount
|
|
|
|
Once the dev server is running,
|
|
|
|
- Upload a file:
|
|
devcam put file ~/camlistore/COPYING
|
|
- Create a permanode:
|
|
devcam put permanode
|
|
- Use the UI: http://localhost:3179/ui/
|
|
|
|
Before submitting a patch, you should check that all the tests pass with:
|
|
|
|
$ devcam test
|
|
|
|
You can use your usual git workflow to commit your changes, but for each
|
|
change to be reviewed you should merge your commits into one before submitting
|
|
to gerrit for review.
|
|
You should also try to write a meaningful commit message, which at least states
|
|
in the first sentence what part of camlistore this commit is affecting. The
|
|
following text should state what problem the change is addressing, and how.
|
|
An example would be:
|
|
|
|
"
|
|
HACKING: add tips about writing a commit message.
|
|
|
|
First time committers are not always aware about good commit message etiquette.
|
|
These few notes should help them.
|
|
"
|
|
|
|
If your commit is adding or updating a vendored third party, you must indicate
|
|
in your commit message the version (e.g. git commit hash) of said third party.
|
|
|
|
You can optionally use our pre-commit hook so that your code gets gofmt'ed
|
|
before being submitted (which should be done anyway).
|
|
|
|
$ cd .git/hooks
|
|
$ ln -s ../../misc/pre-commit.githook pre-commit
|
|
|
|
Finally, submit your code to gerrit with:
|
|
|
|
$ devcam review
|
|
|
|
Please update this file as appropriate.
|