This is breaking the ability to specify an alternate DEPS file, and do
things like sync release tags where DEPS is still from svn and we need
.DEPS.git to do a git checkout.
R=iannucci@chromium.org, szager@chromium.org
BUG=407049
Review URL: https://codereview.chromium.org/511533003
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@291665 0039d316-1c4b-4281-b951-d872f2087c98
This is primarily a hack to enable the chromeos ebuild.
BUG=367027
TBR=iannucci@chromium.org,mmoss@chromium.org
Review URL: https://codereview.chromium.org/490233003
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@291075 0039d316-1c4b-4281-b951-d872f2087c98
Original CL: https://codereview.chromium.org/440263002/
Many people* have complained on chromium-dev about the long times
required to perform a full fetch over a DSL. This seems to be mostly
due to the huge size of chromium's history (~9 GB). On the other side,
not everybody is interested in downloading the full git history of
the projects. The size of git packs required to fetch a working HEAD
is one order of magnitude smaller (1.5 GB).
This change makes it possible to perform a shallow fetch (in a way
which is consistent with DEPS, leveraging git templates on clone),
reducing fetch times by 80% for those not interested in the history.
* See:
[chromium-dev] "fetch chromium" keeps hanging/getting stuck on Windows 7
[chromium-dev] Initial checkout with git taking long
[chromium-dev] Trying to get latest source code fails when fetching
[chromium-dev] Gclient sync takes too long
BUG=228996
TBR=iannucci@chromium.org,szager@chromium.org,wtc@chromium.org
Review URL: https://codereview.chromium.org/440273002
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@287793 0039d316-1c4b-4281-b951-d872f2087c98
Reason for revert:
Broke the WebRTC waterfall:
http://build.chromium.org/p/tryserver.webrtc/builders/win/builds/3958/steps/gclient%20revert/logs/stdio
Original issue's description:
> Add --no-history option to fetch and gclient for shallow clones.
>
> Many people* have complained on chromium-dev about the long times
> required to perform a full fetch over a DSL. This seems to be mostly
> due to the huge size of chromium's history (~9 GB). On the other side,
> not everybody is interested in downloading the full git history of
> the projects. The size of git packs required to fetch a working HEAD
> is one order of magnitude smaller (1.5 GB).
> This change makes it possible to perform a shallow fetch (in a way
> which is consistent with DEPS, leveraging git templates on clone),
> reducing fetch times by 80% for those not interested in the history.
>
> * See:
> [chromium-dev] "fetch chromium" keeps hanging/getting stuck on Windows 7
> [chromium-dev] Initial checkout with git taking long
> [chromium-dev] Trying to get latest source code fails when fetching
> [chromium-dev] Gclient sync takes too long
>
> BUG=228996
>
> Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=287606
TBR=iannucci@chromium.org,szager@chromium.org,wtc@chromium.org
NOTREECHECKS=true
NOTRY=true
BUG=228996
Review URL: https://codereview.chromium.org/440263002
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@287637 0039d316-1c4b-4281-b951-d872f2087c98
Many people* have complained on chromium-dev about the long times
required to perform a full fetch over a DSL. This seems to be mostly
due to the huge size of chromium's history (~9 GB). On the other side,
not everybody is interested in downloading the full git history of
the projects. The size of git packs required to fetch a working HEAD
is one order of magnitude smaller (1.5 GB).
This change makes it possible to perform a shallow fetch (in a way
which is consistent with DEPS, leveraging git templates on clone),
reducing fetch times by 80% for those not interested in the history.
* See:
[chromium-dev] "fetch chromium" keeps hanging/getting stuck on Windows 7
[chromium-dev] Initial checkout with git taking long
[chromium-dev] Trying to get latest source code fails when fetching
[chromium-dev] Gclient sync takes too long
BUG=228996
Review URL: https://codereview.chromium.org/437903002
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@287606 0039d316-1c4b-4281-b951-d872f2087c98
Also cast recursedeps to a set. We'll continue
to support using a list literal form in DEPS for
now.
R=iannucci@chromium.org,agable@chromium.org
BUG=393000
Review URL: https://codereview.chromium.org/385123008
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@283474 0039d316-1c4b-4281-b951-d872f2087c98
Created the 'GitRefish' class to centralize 'git' refish parsing and consistent
usage by 'gclient' 'git' code.
BUG=373504
TEST=localtest
R=agable@chromium.org, iannucci@chromium.org
Review URL: https://codereview.chromium.org/328843005
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@281553 0039d316-1c4b-4281-b951-d872f2087c98
Now that recurselist is no longer a list, it doesn't make
sense to call it recurselist. recurseset is available, but
that's not as easy to read/say compared to recurselist.
Call this recursedeps, instead.
R=iannucci@chromium.org
BUG=390246
Review URL: https://codereview.chromium.org/363103002
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@281107 0039d316-1c4b-4281-b951-d872f2087c98
It's possible to tell gclient to use a different
"deps" file from the default DEPS through the "deps_file"
variable in the .gclient file.
If this file is missing, fallback to DEPS (the
default).
BUG=390700
Review URL: https://codereview.chromium.org/368713002
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@280921 0039d316-1c4b-4281-b951-d872f2087c98
Previously, recursion overrides were only available by setting
a numeric 'depth' value in a DEPS file. This meant that it
was not possible to control recursion per-dependency entry.
This change adds a recurselist variable with a list structure.
If a named dependency is present in the list, then gclient will
recurse into that dependency's DEPS.
As part of this change, I move the recursion controls off of
DependencySetting and onto Dependency. The new setup of being
based on Dependency allows access to the dependency's name.
The controls are only called from Dependency instances. They
have always needed access to self.parent (in the Dependency
context), so this should be more correct than the previous setup.
BUG=390246
Review URL: https://codereview.chromium.org/331373009
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@280690 0039d316-1c4b-4281-b951-d872f2087c98
Currently, only top-level solutions may be pinned via --revision. With this, we can:
gclient sync --revision src/third_party/WebKit@deadbeef
BUG=
Review URL: https://codereview.chromium.org/290443003
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@271571 0039d316-1c4b-4281-b951-d872f2087c98
This occurs for svn checkouts when the DEPS change from:
third_party/skia/gyp
third_party/skia/include
third_party/skia/src
to:
third_party/skia
First, gclient deletes/moves third_party/skia to make room for the new checkout.
When finished, it notices that the three subdirectories under skia are now
"unversioned" according to .gclient_entries, even though they are part of Skia
repo. On the bots, this causes them to be deleted.
There is a check to determine whether the thought-to-be unversioned directories
are actually subdirectories of another checkout, but it doesn't work in the svn
case because the check assumes that, if they are subdirectories of another
checkout, it must be an svn checkout. scm.GetCheckoutRoot() returns None
because it can't find an svn checkout containing those subdirectories. None is
not in gclient_entries, so the directories get deleted.
BUG=
Review URL: https://codereview.chromium.org/275103009
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@270133 0039d316-1c4b-4281-b951-d872f2087c98
So that bot_update can use them to figure out which repo correspons to where.
BUG=370503
Review URL: https://codereview.chromium.org/268373003
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@268875 0039d316-1c4b-4281-b951-d872f2087c98
Evidence indicates that running non-builtin git commands is very
slow in msysgit, slow enough to dominate the running time of
gclient sync. With this change, gclient never shells out to
git-cache; it import the lib directly instead.
R=agable@chromium.org,hinoka@chromium.org
BUG=
Review URL: https://codereview.chromium.org/229653002
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@262759 0039d316-1c4b-4281-b951-d872f2087c98
Features:
- Non-verbose output is now limited to a one-line progress
indicator.
- Verbose output is now collated per subprocess. As soon as a
subprocess finishes, its full output is dumped to terminal.
- Verbose output is prefixed with timestamps representing elapsed
time since the beginning of the gclient invocation.
- git progress indicators ("Receiving objects", etc.) are limited to
one line every 10 seconds.
- In both verbose and non-verbose mode, if a failure occurs, the
full output of the failed update operation is dumped to terminal
just before exit.
- In the event that updates are progressing, but slowly,
"Still working" messages will be printed periodically, to pacify
users and buildbots.
BUG=
R=hinoka@google.com
Review URL: https://codereview.chromium.org/227163002
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@262500 0039d316-1c4b-4281-b951-d872f2087c98
Instead of having custom logic for dealing with cache directories, use
git_cache.py to populate caches.
Also fixes a bug in git_cache.py where it was looking for lockfiles in cwd rather than the cache dir.
Other changes:
* _Run now returns output.
* Always print to stdout in CheckCallAndFilterOutput, even if it gets a carriage return. This is done because git progress report are carriage returns and not newlines and we don't want everything on the same line and not strip out the CRs.
* Removed members changed tests, its not very useful to know a new import is added.
BUG=339171
Review URL: https://codereview.chromium.org/180243006
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@254248 0039d316-1c4b-4281-b951-d872f2087c98
It's not true (anymore?) that the number of SCM jobs for gclient sync equals the
number of cores, thus the new text is less specific.
BUG=none
Review URL: https://codereview.chromium.org/184733007
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@254242 0039d316-1c4b-4281-b951-d872f2087c98
Given that we search for the gclient root in ancestor directories based on the file name, specifying a file with separators doesn't make a lot of sense.
BUG=336946
R=iannucci@chromium.org
Review URL: https://codereview.chromium.org/150633004
git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@249077 0039d316-1c4b-4281-b951-d872f2087c98
szager@chromium.org
tandrii@chromium.org
mmoss@chromium.org
dnj@chromium.org
iannucci@chromium.org
szager@chromium.org
dyen@chromium.org
primiano@chromium.org
cmp@chromium.org
smut@google.com
dnj@chromium.org
hinoka@chromium.org
borenet@google.com
scr@chromium.org
rnk@chromium.org
hinoka@google.com
tnagel@chromium.org
mmoss@chromium.org
rdsmith@chromium.org