-
-
docs/codebase/custom-forks.txt (Diff revision 1) I don't think people need to create a server (that's only if they want to serve it to people), they just need a clone. It's perfectly valid to do a clone straight from the reviewboard public clone URL, commit some changes locally, then periodically fetch and merge/rebase to stay current with upstream. I'd argue that's maybe even the way most people maintaining a private fork for their organization would do it. Also, our->your.
-
docs/codebase/getting-started.txt (Diff revision 1) Two comments here. I'd change "You should also use a..." to "Some people find it helpful to use a..." gitx -> gitk
Add docs on developing against Review Board and maintaining forks
Review Request #1014 — Created Sept. 1, 2009 and submitted
Information | |
---|---|
chipx86 | |
Review Board | |
master | |
Reviewers | |
reviewboard | |
This is a new batch of docs that detail how to begin working on contributing to Review Board. It explains how to set up a development tree, the basics of branches, and contributing changes back. There's also some docs in there for maintaining a fork of Review Board using GitHub or a custom solution.
Built the docs and read through them a bit.
Change Summary:
* Make it more clear why you'd use a custom fork in a centralized place. * Fix a case where "gitx" was referenced instead of "gitk." * Make it sound less like a requirement to use gitk/gitx.
Diff: |
Revision 2 (+495) |
---|