Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
Ruby
branch: master

Fetching latest commit…

Cannot retrieve the latest commit at this time

Failed to load latest commit information.
released Adding 3.0.3.xml based on 3.0.3-1713 and 3.0.3-MP1.xml based on 3.0.3…
toy Update toy-ceej
.gitignore added tmp to .gitignore
README.markdown Let the readme point to tlm's readme
askeladden.xml CBD-1498: Move forestdb out of couchbaselabs
branch-1.8.1-mb-5845.xml Be more specific when pointing to a tag for 1.8.1 hotfix branch
branch-1.8.1.xml MB-6757: Make sure 1.8.1 build set with fixed release revision
branch-2.0.1.xml CBD-926: Memcached should use the 2.0 branch
branch-2.0.xml updated 2.0.0 manifest file
branch-2.1.0.xml CBD-946: healthchecker now has 2.1.0 branch
branch-builddeps.xml create manifest file for builddeps project
branch-master.xml MB-13647: Add subjson to branch-master.xml
external-override-1.8.1.xml All manifests should use the old-master gperftools branch
external-override-2.0.1.xml All manifests should use the old-master gperftools branch
external-override-2.0.xml All manifests should use the old-master gperftools branch
external-override-2.0b.xml All manifests should use the old-master gperftools branch
external-override-2.0c.xml All manifests should use the old-master gperftools branch
external-override-2.0dp4.xml use OTP_R14B03 for dp4 and OTP_R14B04 for 1.8 and 2.0
external-override-2.1.0.xml All manifests should use the old-master gperftools branch
external-override-2.1.1.xml All manifests should use the old-master gperftools branch
external-override-2.2.0.xml All manifests should use the old-master gperftools branch
external-override-2.2.1.xml All manifests should use the old-master gperftools branch
external-override-2.5.0.xml fix revisions to RC1 (2.5.0-994)
external-override-2.5.1-MB-11187.xml MB-11187: Add v8 dependencies
external-override-2.5.1.xml CBD-1246: 2.5.1 manifests are copies of 2.5.0
external-override-2.5.2.xml MB-12274: Add 2.5.2 override manifests
external-override-3.0.0.xml MB-11216, MB-11145: updating 3.0.0 builds to gperftools 2.2
external-override-3.0.1.xml CBD-1431: 3.0.1 overrides copies of 3.0.0 overrides
external-override-3.0.2.xml Adding override manifests for 3.0.2
external-override-3.0.x.xml Adding manifests for 3.0.x releases (3.0.3 and later sustaining relea…
external-override-builddeps.xml create manifest file for builddeps project
external-override-master.xml Revert "MB-11406: Revert *master* only to Erlang R14, for performance…
fetch-manifest.rb Yet more tweaking of git fetch
masterish.xml CBD-1493: Add a *temporary* manifest that is sort of like
override-1.8.1.xml MB-8102: use commits from released/1.8.1.xml
override-2.0.1.xml All manifests should use the old-master gperftools branch
override-2.0.xml All manifests should use the old-master gperftools branch
override-2.0b.xml All manifests should use the old-master gperftools branch
override-2.0c.xml All manifests should use the old-master gperftools branch
override-2.1.0.xml All manifests should use the old-master gperftools branch
override-2.1.1.xml CBSE-811: 2.1.1 uses override-2.1.1.xml
override-2.2.0.xml RC1: 2.2.0-817
override-2.2.1.xml All manifests should use the old-master gperftools branch
override-2.5.0.xml fix revisions to RC1 (2.5.0-994)
override-2.5.1-MB-11187.xml MB-11187: Add v8 dependencies
override-2.5.1.xml CBD-1246: 2.5.1 manifests are copies of 2.5.0
override-2.5.2.xml MB-12274: Add 2.5.2 override manifests
override-3.0.0.xml Revert "Beta-2 refresh: Re-building build 1055 plus two couchbase-cli…
override-3.0.1.xml CBD-1431: 3.0.1 overrides copies of 3.0.0 overrides
override-3.0.2.xml Adding override manifests for 3.0.2
override-3.0.x.xml Adding manifests for 3.0.x releases (3.0.3 and later sustaining relea…
override-master.xml Revert "MB-11406: Revert *master* only to Erlang R14, for performance…
override-sync-gateway.xml CBLT-39: Build package for sync gateway
patch-manifest.rb Automatically generate manifest files based on gerrit-refspec
rel-1.8.1.xml MB-8102: use commits from released/1.8.1.xml
rel-2.1.1.xml CBDE-881: merge couchdb changes to 2.1.0 branch for 2.1.1 patch
rel-2.2.0.xml MB-11037: ep-engine uses branch "MB-11037", everything else at 2.2.0-837
rel-2.2.1.xml MB-9169: neither master nor 3.0.0 have needed changes from 2.2 branch
rel-2.5.0.xml MB-10227 branch for ns_server, else same as released/2.5.0.xml
rel-2.5.1.xml MB-12451 Verification build to test MCD memory leak
rel-2.5.2.xml MB-12274: Also point couchdbx-app to "2.5.1.1" branch
rel-3.0.0.xml MB-12185: Reference memcached from "couchbase" github remote
rel-3.0.1.xml MB-12185: Reference memcached from "couchbase" github remote
rel-3.0.2.xml Temporarily reset rel-3.0.2.xml to 3.0.2-1636 for a rebuild.
rel-3.0.x.xml MB-14057: Update rel-3.0.x.xml for 3.0.3-MP1
sherlock.xml Revert "Temporarily set sherlock.xml back to 1817 + 2i fixes"
sync-gateway-1.0.0.xml CBLT-41: build out of stable branch

README.markdown

Which Manifest Do I Use?

Released Versions of Couchbase Server

When we make a release, we take the manifest emitted from the builder and store it in the released/ directory. This manifest only has exact commit SHAs, so that it explicitly describes which revision was used, in both Couchbase and external repositories.

It also gives the revision of the "voltron" repo used in the build. Voltron contains build instructions --- like RPM spec files -- that are used at the top level before the manifest is used to fetch files from the source repos. Because the voltron repo is private, and is outside the scope of the "repo" tool, it is included in released/ manifests as a comment.

To replicate a released build use a manifest from the released/ directory.

Versions of Couchbase Server Prior to Release

If you want to build the development branch you should use "branch-master.xml".

While preparing for a product release, we build using one of the manifests in the top-level directory. Prior to 2.2.0 the files were called "branch-branch-name.xml", and starting with 2.2.0 we used files called "rel-release-name.xml"

This was to signify a change in process, in which stopped making release-specific branches (named for the release), unless a such branch was needed (and is no longer named for the release). Thus we had:

      branch-1.8.1.xml
      branch-2.0.1.xml
      branch-2.0.xml
      branch-2.1.0.xml

And going forward we have:

      rel-2.1.1.xml
      rel-2.2.0.xml
      rel-2.2.1.xml
      rel-3.0.0.xml

You will not need to use any of these manifests unless you are contributing changes towards a Couchbase release.

Couchbase Experimental Builds

The toy/ directory is used by Couchbase developers for experimental builds, and so are probably not of interest to anyone not familiar with the context of the experiment.

Building With Repo

See the readme in the correct branch for tlm for the exact steps on how to build the desired version.

Get Repo

(if you didn't install from homebrew, or aren't running on Mac OS X)

Get the latest version from the google project page.

Clone the Manifest

For <branch_name> below, you probably want to one of the latest branches in released when getting started. As of this writing, that is released/2.2.0.xml unless you are working on a maintenance or experimental branch.

$ mkdir couchbase
$ cd couchbase
$ repo init -u git://github.com/couchbase/manifest.git -m <branch_name>
$ repo sync

Build

$ make
Something went wrong with that request. Please try again.