Skip to content

C
Chromium_Depot_tools
Switch branch/tag
  1. 14 Nov, 2019 1 commit
  3. 30 Oct, 2019 1 commit
  5. 21 Oct, 2019 1 commit
  7. 11 Oct, 2019 1 commit
    • Marc-Antoine Ruel's avatar
      python3 improvements · 8e57b4bc
      Marc-Antoine Ruel authored 
      Ran:
  vi $(git grep --name-only iteritems | grep -v third_party)
  vi $(git grep --name-only itervalues | grep -v third_party)
  vi $(git grep --name-only 'print ' | grep -v third_party)

and edited the files quickly with adhoc macros. Then ran in recipes/:
  ./recipes.py test train

There was only a small subset of files that had been updated to use
six.iteritems() and six.itervalues(). Since the dataset size that is
being used in gclient is small (pretty much always below 200 items),
it's better to just switch to .items() right away and take the temporary
performance hit, so that we don't need to come back to rewrite the code.

Recipe-Nontrivial-Roll: build
Bug: 984182
Change-Id: I5faf11486b66b0d73c9098ab0f2ce1b15a45c53e
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/tools/depot_tools/+/1854900
Commit-Queue: Edward Lesmes <ehmaldonado@chromium.org>
Reviewed-by: 's avatarEdward Lesmes <ehmaldonado@chromium.org>
Auto-Submit: Marc-Antoine Ruel <maruel@chromium.org>
      8e57b4bc
  9. 28 Aug, 2019 1 commit
  11. 23 Aug, 2019 1 commit
  13. 21 May, 2019 1 commit
  15. 02 May, 2019 1 commit
    • Bruce Dawson's avatar
      Fix multiple confusingly escaped regex strings · 9c062012
      Bruce Dawson authored 
      Python (prior to 3.8) treats meaningless string escape sequences as if
they were a slash followed by the character. That is, '\w' == '\\w'.
Python 3.8 rejects this, and it's confusing. This change fixes seven of these
regex strings found in depot_tools (through a regex search, natch). Most of
the fixes don't actually change the value of the strings, and this was
manually verified:

>>> '(/c(/.*/\+)?)?/(\d+)(/(\d+)?/?)?$' == r'(/c(/.*/\+)?)?/(\d+)(/(\d+)?/?)?$'
True
>>> '#\s*OWNERS_STATUS\s+=\s+(.+)$' == r'#\s*OWNERS_STATUS\s+=\s+(.+)$'
True
>>> 'COM\d' == r'COM\d'
True
>>> '^\s+Change-Id:\s*(\S+)$' == r'^\s+Change-Id:\s*(\S+)$'
True
>>> 'ETag:\s+([a-z0-9]{32})' == r'ETag:\s+([a-z0-9]{32})'
True

Two exceptions were the regex expressions in filter_demo_output.py and scm.py.
These were turned into raw strings despite this changing the value of the
string passed to re. This works because re supports the \x, \d, \w, \t, and
other escape sequences needed to make this work.

TL;DR - use raw strings for regex to avoid melting your brain. If bulk changing
regex strings to raw watch out for double-slashes.

Bug: 958138
Change-Id: Ic45264cfc63e8bae9cfcffe2cd88a57c2d3dcdae
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/tools/depot_tools/+/1590534
Commit-Queue: Bruce Dawson <brucedawson@chromium.org>
Reviewed-by: 's avatarDirk Pranke <dpranke@chromium.org>
      9c062012
  17. 25 Apr, 2019 1 commit
    • Daniel Bratell's avatar
      Speed up some really slow OWNERS operations for large/huge patches · b2b66999
      Daniel Bratell authored 
      The current owners systems scales badly on the number of files in a
patch, on the number of OWNERS files and on the number of "set noparent"
rules. This patch addresses all three of those.

If you have a patch with many (thousands) of files, you run into a lot
of repeated work because the parent directories are visited for every
file. By using a cache or remembering what directories have been
visited, a lot of work can be avoided.

If you have many OWNERS files or "set noparent" rules in scope of a
patch, owners and stop_looking lookups became slow.  By splitting the
rules by longest glob-free directory path, you get much smaller lists
to process, which makes the code much faster.

(Test case with "all the files" went from >15 minutes to 30 seconds).

This saves about 2.5 second for git cl upload with a patch of
350 files spread over the tree.

The addition of many noparent rules in the Chromium tree might have
been the major reason this is needed, but there are also more files to
change, allowing larger patches.

Bug: 920591
Change-Id: If21178746ca9b88c2c07d265bd583b556d1734b7
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/tools/depot_tools/+/1404172Reviewed-by: 's avatarDirk Pranke <dpranke@chromium.org>
Auto-Submit: Daniel Bratell <bratell@opera.com>
Commit-Queue: Daniel Bratell <bratell@opera.com>
      b2b66999
  19. 01 Nov, 2018 1 commit
  21. 05 Sep, 2018 1 commit
  23. 19 Apr, 2018 1 commit
  25. 06 Nov, 2017 1 commit
  27. 16 Jun, 2017 1 commit
  29. 31 May, 2017 1 commit
  31. 15 May, 2017 1 commit
    • Aaron Gable's avatar
      owners: handle CLs which only have partial OWNERS · 93248c5c
      Aaron Gable authored 
      If every file in a change has OWNERS, then the code would find
them fine. Similarly, if no files has OWNERS, then this code would
return an empty set just fine.

But if some files had OWNERS while others didn't, it would crash
when it tried to find an OWNER for file 'foo' while all the possible
OWNERS only provided coverage for file 'bar'.

This code purges the list of possible OWNERS as they become useless
for providing additional coverage, and returns whatever set we have
accumulated so far when the set of possible OWNERS becomes empty.

R=iannucci@chromium.org

Bug: 715062
Change-Id: I408601bd89379381db1cc7df56beed97ab3c27e6
Reviewed-on: https://chromium-review.googlesource.com/506239
Commit-Queue: Aaron Gable <agable@chromium.org>
Reviewed-by: 's avatarRobbie Iannucci <iannucci@chromium.org>
      93248c5c
  33. 20 Apr, 2017 1 commit
  35. 17 Apr, 2017 1 commit
  37. 05 Apr, 2017 1 commit
  39. 04 Apr, 2017 1 commit
    • Jochen Eisinger's avatar
      Add support for a global status files for OWNERS · 72606f8c
      Jochen Eisinger authored 
      This allows for having some global comments such as timezones or
long-term unavailability.

The comments go into build/OWNERS.status (that way, they should be
available in all repos that map in build/ for the gn config files).
The local can be overwritten in codereview.settings.

The format is

email: status

Comments (starting with #) are allowed in that file, but they're ignored.

BUG=694222
R=dpranke@chromium.org

Change-Id: I49f58be87497d1ccaaa74f0a2f3d373403be44e7
Reviewed-on: https://chromium-review.googlesource.com/459542
Commit-Queue: Jochen Eisinger <jochen@chromium.org>
Reviewed-by: 's avatarDirk Pranke <dpranke@chromium.org>
      72606f8c
  41. 07 Mar, 2017 1 commit
  43. 16 Dec, 2016 1 commit
  45. 16 Sep, 2016 1 commit
  47. 14 Jul, 2016 2 commits
    • dtu's avatar
      Fix per-file owners check for deleted files. · 944b6053
      dtu authored 
      Previously if you deleted a file that you had per-file owners on, it would fail
the owners check. This fixes that.

Originally, owners.Database used glob to enumerate the directory and added all
the matching files in the directory to some dicts holding the owners
information. If a CL deleted a file, it'd no longer be on the filesystem, so it
wouldn't be in these dicts. There'd be no per-file owners information for it.

With this patch, the Database no longer enumerates individual files. It instead
keeps track of the glob patterns and checks the CL's files against the patterns
at lookup time.

BUG=622381
TEST=tests/owners_unittest.py && tests/owners_finder_test.py  # Unit test included.

Review-Url: https://codereview.chromium.org/2148153002
      944b6053
    • mbjorge's avatar
      Fix relative file: paths in OWNERS with roots other than '/' · f2d73522
      mbjorge authored 
      If an OWNERS file used the file: directive with a relative file
path, but was using a root other than '/' (e.g.
'/path/to/my/real/root'), then the include resolver would incorrectly
leave a leading '/' on the include path. When os_path.join was then
called, the leading '/' meant the path was treated as an absolute path
and the join did not behave as expected.

Review-Url: https://codereview.chromium.org/2148683003
      f2d73522
  49. 16 Apr, 2015 1 commit
  51. 20 Sep, 2013 1 commit
  53. 28 Feb, 2013 1 commit
  55. 23 Feb, 2013 1 commit
    • dpranke@chromium.org's avatar
      Change the OWNERS check to print files, not directories · 6b1e3ee9
      dpranke@chromium.org authored 
      Currently, when we run the OWNERS check, we print the list of directories
that contain the relevant OWNERS files for any modified files in a change
still needing approval. 

This has two problems:

1) if we bubble all the way up to the top level OWNERS, we print "" instead of
"src/" or something more useful (bug 157191)

2) for OWNERS files that contain per-file set-noparent entries (like changes to IPC messages), this can be really confusing because an owner of other stuff in the directory might've approved things already.

This change will now print the list of files in the CL that are still unapproved.
This might be a lot more verbose (since you get N lines rather than 1 for N files in a given directory), but hopefully it'll be clearer in the two cases above.

Also, this change takes care of some lingering clean-up in the code to rename some methods to be clearer.

R=maruel@chromium.org
BUG=157191




Review URL: https://chromiumcodereview.appspot.com/12314044

git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/depot_tools@184219 0039d316-1c4b-4281-b951-d872f2087c98
      6b1e3ee9
  57. 18 Jan, 2013 1 commit
  59. 20 Dec, 2012 1 commit
  61. 19 Dec, 2012 3 commits
  63. 18 Dec, 2012 1 commit
  65. 13 Dec, 2012 1 commit
  67. 03 Dec, 2012 1 commit
  69. 20 Oct, 2012 2 commits
  71. 17 Oct, 2012 1 commit