This can be useful to create a new manifest from an existing client,
especially if the client wants to use the "-r" option to set each
project's revision to the current commit SHA-1, making a sort of a
tag file that can be used to recreate this exact state elsewhere.
Signed-off-by: Shawn O. Pearce <sop@google.com>
The manifest files now permit removing a project so the user can
either keep it out of their client, or replace it with a different
project using an entirely different configuration.
Signed-off-by: Shawn O. Pearce <sop@google.com>
This way users can add forks they know about to an existing project
that was already declared in the primary manifest. This is mostly
useful with the Linux kernel project, where multiple forks is quite
common for the main upstream tree (e.g. Linus' tree), a platform
architecture tree (e.g. ARM) and a device specific tree (e.g. the
msm7k tree used by Android).
Signed-off-by: Shawn O. Pearce <sop@google.com>
By setting a project-name on a remote nested within a project forks
of a project like the Linux kernel can be easily handled by fetching
all relevant forks into the same client side project under different
remote names. Developers can create branches off different remotes
using `git checkout --track -b $myname $remote/$branch` and later
`repo upload` automatically redirects to the proper fork project
in the code review server.
Signed-off-by: Shawn O. Pearce <sop@google.com>
The mirror option downloads a complete forrest (as described by the
manifest) and creates a replica of the remote repositories rather
than a client working directory. This permits other clients to
sync off the mirror site.
A mirror can be positioned in a "DMZ", where the mirror executes
"repo sync" to obtain changes from the external upstream and
clients inside the protected zone operate off the mirror only,
and therefore do not require direct git:// access to the external
upstream repositories.
Signed-off-by: Shawn O. Pearce <sop@google.com>
Whatever branch name we checked the manifest out from is the name
we want to reflect throughout the rest of the projects, e.g. within
the special "m/" remote space.
This reduces the difference between different branches within the
manifest file.
Signed-off-by: Shawn O. Pearce <sop@google.com>
Prior to open-sourcing repo we had manifests in two different
layouts; one where the manifest was a straight-up git clone, and
one where the manifest was our bare repository with symlink work
tree format (identical to what our projects use). Only the latter
form is created or used by repo at this point, so the transition
code to handle the straight-up git clone is not necessary.
Signed-off-by: Shawn O. Pearce <sop@google.com>
Now that repo relies only on the git data stream (as it is much
faster to download through) we don't really need to be parsing the
<snapshot> elements within manifest. Its a lot of complex code to
convert the tar (or zip) through to a fast import stream, and we
just aren't calling it anymore.
Signed-off-by: Shawn O. Pearce <sop@google.com>
This way we can build more than one Manifest instance in memory
and not muck around with the Editor configuration each time we
build a new instance.
Signed-off-by: Shawn O. Pearce <sop@google.com>
By creating a .repo/local_manifest.xml the user can add extra
projects into their client space, without touching the main
manifest script.
For example:
$ cat .repo/local_manifest.xml
<?xml version="1.0" encoding="UTF-8"?>
<manifest>
<project path="android-build"
name="platform/build"
remote="korg"
revision="android-1.0" />
</manifest>
Signed-off-by: Shawn O. Pearce <sop@google.com>
